From: Leam Hall Date: Tue, 20 Aug 2019 18:01:14 GMT Subject: Re: Only track built files for final output? Message-ID: In-Reply-To: <20190820174640.n3elekpi6l4vwamp@localhost.localdomain> On 8/20/19 1:46 PM, Pratyush Yadav wrote: > On 20/08/19 08:21AM, Leam Hall wrote: >> Hey all, a newbie could use some help. >> >> We have some code that generates data files, and as a part of our build >> process those files are rebuilt to ensure things work. This causes an issue >> with branches and merging, as the data files change slightly and dealing >> with half a dozen merge conflicts, for files that are in an interim state, >> is frustrating. The catch is that when the code goes to the production >> state, those files must be in place and current. >> >> We use a release branch, and then fork off that for each issue. Testing, and >> file creation, is a part of the pre-merge process. This is what causes the >> merge conflicts. >> >> Right now my thought is to put the "final" versions of the files in some >> other directory, and put the interim file storage directory in .gitignore. >> Is there a better way to do this? >> > > My philosophy with Git is to only track files that I need to generate > the final product. I never track the generated files, because I can > always get to them via the tracked "source" files. > > So for example, I was working on a simple parser in Flex and Bison. Flex > and Bison take source files in their syntax, and generate a C file each > that is then compiled and linked to get to the final binary. So instead > of tracking the generated C files, I only tracked the source Flex and > Bison files. My build system can always get me the generated files. > > So in your case, what's wrong with just tracking the source files needed > to generate the other files, and then when you want a release binary, > just clone the repo, run your build system, and get the generated files? > What benefit do you get by tracking the generated files? For internal use I agree with you. However, there's an issue. The generated files are used by another program's build system, and I can't guarantee the other build system's build system is built like ours. It seems easier to provide them the generated files and decouple their build system layout from ours.