Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html