Re: Only track built files for final output?

[Phil Hord <phil.hord@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:

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