Re: [ANNOUNCE] Git v2.8.0-rc2

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mar 22, 2016, 10:00 UTC
Message-ID: <56F117C7.2030900@drmicha.warpmail.net>
In-Reply-To: <xmqqr3f3lhvw.fsf@gitster.mtv.corp.google.com>

Junio C Hamano venit, vidit, dixit 21.03.2016 21:01:

Show 17 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> I think this is a general question about how to track build
>> products.  The proper place may be in a tree that is referenced
>> from a note or so.
> 
>> Maybe I shouldn't consider git.pot a build product - I don't know,
>> as I honestly don't know why we treat it the way we do.
> 
> I think your LaTeX output analogy is interesting.  When working with
> other people editing a single document, each person may update the
> build product (.dvi or .pdf or whatever) in his branch and when you
> merge other people's work, this would create an unresolvable mess
> but that is perfectly fine, because you wouldn't even attempt to
> merge the build product.  Instead, you would merge the source
> material, run the formatter, and pretend as if its output is the
> result of the merging of .dvi or .pdf or whatever.

I have to confess that that is actually my main use of git outside of git.git, and that my "solution" is tracking .pdf etc. and using a pre-commit (and pre-merge) hook that prevents me from commiting a state where "make -q" is not successful. Still not perfect, partly due to the fact that make is timestamp based, not checksum based. ("Use scons", I know...)

> But then we need to step back and consider the reason why we keep
> the build product in the first place.  Presumably that is to help
> those who want to consume the build product without having the
> toolchain to build from the source.

That is certainly a good use case - see, e.g., our documentation. On the other hand, "make pot" has very light toolchain requirements compared to "make doc".

Another use case is a "poor man's release accountability" - a build result depends on the actual toolchain version also, not just the source, and tracking a build stores a copy of a build result that you handed out in class, deployed somewhere, ...

Show 5 quoted lines

> If that is the case, perhaps it
> is also a valid workflow for these collaborating authors of a single
> document not to update the build product, if they know that nobody
> cares about how the final output looks like on their individual
> fork, until their work is merged to some "mainline".

Wouldn't that reasoning imply that there's no point in tracking at all? That is, in tracking in the main tree.

Show 6 quoted lines

> The primary consumers of git.pot build product are the l10n teams,
> and I do not think that they want to (or it is practical to ask them
> to) work on translating new messages on individual topics code-side
> people work on.  So perhaps it is a valid workflow to leave git.pot
> behind until i18n coordinator declares "it is time to catch up" and
> regenerates it at some "snapshot" time in the development cycle.

Yes, I just think that "git.pot" in the main tree sends a wrong signal because it is out of sync in the sense that it is not "make pot"-clean. The main tree is the place for snapshots (especially not non-rolling ones). Possible alternatives:

- Do not track git.pot at all.
It can be recreated easily, and (unless I'm horribly mistaken) only l10n
people need it ; everyone else needs the .po files, or rather .mo.

- Make po/ a submodule.
Submodules are exactly our way of stating "this depends on a tree with a
separate history and/or different release cycle; commit bar in the super
project is 'based' on commit foo in the submodule (but not the other way
round!)

- Do it like the extra prebuild doc-branches.

- Snapshot with tags (similar to github releases).

With current master at 047057b, the contained git.pot is actually not (guaranteed to be) the one containing the translatable strings from that tree. If you want to find out which one, you'd have to "git log -1 po/git.pot" and rely on the fact that Jiang's tree actually does keep git.pot in-sync.

Somehow, submodules seem to best represent that one-way dependency. (I'm not a submodule user at all.)

Michael

P.S.: git.pot is both a build product as well as a build/install requirement, so my tex/pdf analogy does not apply fully.