git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Jiang Xin <worldhello.net@gmail.com>
Subject: Re: [ANNOUNCE] Git v2.8.0-rc2
Date: Thu, 17 Mar 2016 09:15:44 -0700	[thread overview]
Message-ID: <xmqqio0l13nz.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <56EAC47F.6000708@drmicha.warpmail.net> (Michael J. Gruber's message of "Thu, 17 Mar 2016 15:51:43 +0100")

Michael J Gruber <git@drmicha.warpmail.net> writes:

> So, in short, I do believe there is a good reason for the "out of sync"
> git.pot. That doesn't make the negative side effect that I describe any
> less true, and I'm looking for ways to ammeliorate that. Something as
> easy as "make check" or "make test-lint".

Yes, I agree fully with the last sentence.  I think the task
probably needs two building blocks:

 - A tool to generate up-to-date git.pot contents and store into a
   given filename.

 - A tool that can be used to compare two versions of a .pot file,
   stored as two separate files in the filesystem, without the noise
   that comes from auto-generator (e.g. line numbers, the difference
   of line-wrapping the same messge).

With that, a user can (1) run the former and save the result in
git.pot-before-change before making any change (2) do her work, (3)
run the former again and save the result in git.pot-after-change,
and (4) run the latter between these two.

This is a bit hard to drive from the Makefile, though, as our
Makefile cannot assume people are using Git (they may be working off
of a tarball extract to produce a one-liner patch), and there is the
issue of "then how do we ensure that the user runs the former first
on prestine before starting to hack so that later the result can be
compared?"

But just like the version number generation, it is OK for some
targets to be optional, so perhaps it is OK for this "view pot
changes" task is limited to those who work on their own clone of
Git.  If we add that assumption, then the Makefile target for
"view-pot-changes" would

 - see if untracked file git.pot-$(git rev-parse HEAD) exists (treat
   this as a build artifact, like *.o files).  If it does not exist:

  - check out HEAD to a temporary location elsewhere on the
    filesystem;

  - run the first tool and store the result in the above file.

 - run the first tool in the working tree and store the result in
   another file git.pot-now (treat this file as a build artifact,
   too).

 - run the second tool on these two git.pot files.

Add "git.pot-*" to our .gitignore file, and make sure "make clean"
removes them.

  parent reply	other threads:[~2016-03-17 16:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 23:04 [ANNOUNCE] Git v2.8.0-rc2 Junio C Hamano
2016-03-12  9:11 ` Max Horn
2016-03-14 18:10   ` Junio C Hamano
2016-03-14 15:29 ` Michael J Gruber
2016-03-14 15:30   ` [PATCH] wt-status: allow "ahead " to be picked up by l10n Michael J Gruber
2016-03-14 15:57     ` Junio C Hamano
2016-03-14 15:56   ` [ANNOUNCE] Git v2.8.0-rc2 Junio C Hamano
2016-03-14 17:47     ` Junio C Hamano
2016-03-16 13:33       ` Michael J Gruber
2016-03-16 13:40         ` Duy Nguyen
2016-03-16 15:32           ` Michael J Gruber
2016-03-16 16:30             ` Junio C Hamano
2016-03-17 14:51               ` Michael J Gruber
2016-03-17 15:14                 ` [RFC/PATCH] Makefile: allow po generation through po target Michael J Gruber
2016-03-17 22:42                   ` Junio C Hamano
2016-03-17 16:15                 ` Junio C Hamano [this message]
2016-03-20  9:45         ` [ANNOUNCE] Git v2.8.0-rc2 Jiang Xin
2016-03-20 15:11           ` Michael J Gruber
2016-03-21 20:01             ` Junio C Hamano
2016-03-22 10:00               ` Michael J Gruber
2016-03-22 17:43                 ` Junio C Hamano
2016-03-15 16:42   ` Jiang Xin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqio0l13nz.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=worldhello.net@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).