Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano <gitster@pobox.com>]

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.

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.  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".

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.