Re: Only track built files for final output?

From: Phil Hord <phil.hord@gmail.com>
Date: Aug 20, 2019, 19:42 UTC
Message-ID: <CABURp0oCvrVxdvkEyBy_Oe-xy7mEM9Yek-Qe9vnxO9MPfR3Vqg@mail.gmail.com>
In-Reply-To: <f899594c-4f57-b941-f4f1-fd3b8f81136a@gmail.com>

On Tue, Aug 20, 2019 at 11:01 AM Leam Hall <leamhall@gmail.com> wrote:

> On 8/20/19 1:46 PM, Pratyush Yadav wrote:

Show 11 quoted lines

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

It becomes a burden to keep build products in the repo over time, for the reasons you already mentioned (they don't merge and you shouldn't try), but also because those build products never go away, leading to repo-bloat. Once you realize the cost is too great, it's often too late to do something about it cheaply. My advice is to keep your source repository clean from the beginning, so it contains only source code.

This means you still have a problem because you want to distribute certified build artifacts. I recommend you use some other tool to handle that, like Artifactory.

I recognize it seems easy to use Git for this because Git already acts like a reliable, portable, trackable file distribution system. But that's secondary to Git's purpose; there are better tools for that. If you must lean on Git for this, I like to isolate the binaries into a submodule so developers who don't want or need them aren't bothered by them, and they can stay out of the way of merges. But submodules present new workflow challenges and will require some study and education. If you want to keep them out of the way of developers, you can keep your source code repo and your artifact repo completely separate and make some "superproject" which contains both of those repos as submodules. The nice feature about this setup is you can positively associate the set of build products with the set of source code that produced them.