On 2023-08-29, Rainer Weikusat <
rweikusat@talktalk.net> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> writes:
On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
[configure & friends in git]
If the files generated from these are also in the repository,
nuisance git dances will have to be performed to deal with them and this >>> will also cause nuisance merge conflicts for updates.
If you merge parallel changes to a primary file from which a secondary
file is generated, you must regenerate the secondary file. The seconary
file should not be merged. (That would be editing, and generated files
are "generated, do not edit", right?)
Precisely. But git will try to merge them nevertheless and the resulting merge conflicts need to be dealt with somehow. A good way to do so is
Never check anything into git which is supposed to generated from
something else also checked into git. In case someone else did this,
remove it.
By and large, and by default, we should follow the configuration
management principle that secondary/derived objects are not put into
version control, only primary ones. This principle agrees with what you
are saying. When not sure, don't check in the derived object.
There are exceptions though.
The real criterion is which way life is easier.
The answer will be different based on whether the software is
distributed in source code form to large numbers of downstream users, or whether it is something built in-house (e.g. proprietary software).
In a source distribution scenario I find these benefits
- every commit of the repo can be checked out and built; the correct
generated files are just there.
- a release can be cut with just:
git tag <release-tag>; git push origin tag <release-tag>
there is no special baseline.
These outweigh the minor issue of merges in generated files.
- If I don't have the generated file (it is not in version control),
it will have to be generated anyway.
- If I have the generated file in version control, and it has been
subject to a merge, it has to be blown away and generated.
This is almost the same except for the extra effort to be aware
of the situation and not accidentally check in the file when it
was silently merged without conflicts.
Tiny effort for a palpable payoff: I can do a "git bisect" and have
the correct versions of generated files at every commit I visit!
If you check out a baseline from ten years ago, you get the
correct ten-year-old configure script or y.tab.c, which
were generated with the version of the generators used at the
time.
Checking in generated files helps with reproducible builds;
to reproduce an old build, you just need the old compilers,
not the old parser generator, AutoTools and whatever else.
--
TXR Programming Language:
http://nongnu.org/txr
Cygnal: Cygwin Native Application Library:
http://kylheku.com/cygnal
Mastodon: @
Kazinator@mstdn.ca
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)