@MSGID: <20230829102534.979@kylheku.com> 90b7ed65
@REPLY:
<877cpdakxu.fsf@doppelsaurus.mobileactivedefense.com> 76470e03
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230829102534.979@kylheku.com>
@RFC-References: 1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> 1@dont-email.me> <87r0nxrvm1.fsf@bsb.me.uk>
1@dont-email.me> <87zg2jrk7t.fsf@bsb.me.uk> 1@dont-email.me>
<87lee2qz5v.fsf@bsb.me.uk> 1@dont-email.me>
<20230823195415.19d4c01e0cb2ca57faf92c07@g{oogle}mail.com> 2@dont-email.me> 1@dont-email.me>
<20230824083325.525@kylheku.com> 1@dont-email.me> GMN3.79590@fx16.iad>
1@dont-email.me> <20230824160017.406@kylheku.com>
<87edjrhz1d.fsf@doppelsaurus.mobileactivedefense.com> <20230825095521.754@kylheku.com>
<87a5ufhtk5.fsf@doppelsaurus.mobileactivedefense.com> <20230825113441.899@kylheku.com>
<877cpdakxu.fsf@doppelsaurus.mobileactivedefense.com>
@TZUTC: -0000
@PID: slrn/pre1.0.4-9 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
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 ; git push origin 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
--- slrn/pre1.0.4-9 (Linux)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5010/352 5015/255 5019/40
5020/715 848 1042 4441
SEEN-BY: 5020/12000 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441