Re: Consist timestamps within a checkout/clone

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 2, 2022, 14:45 UTC
Message-ID: <221102.86leot2ytm.gmgdl@evledraar.gmail.com>
In-Reply-To: <c060312e-0d35-8439-85dd-920b172c90be@xiplink.com>

On Tue, Nov 01 2022, Marc Branchaud wrote:

Show 36 quoted lines

> On 2022-10-31 15:01, Mark Hills wrote:
>> Our use case: we commit some compiled objects to the repo, where compiling
>> is either slow or requires software which is not always available.
>> Since upgrading Git 2.26.3 -> 2.32.4 (as part of Alpine Linux OS
>> upgrade)
>> we are noticing a change in build behaviour.
>> Now, after a "git clone" we find the Makefile intermittently
>> attempting
>> (and failing) some builds that are not intended.
>> Indeed, Make is acting reasonably as the source file is sometimes
>> marginally newer than the destination (both checked out by Git), example
>> below.
>
> A fix for this was proposed in 2018 and dismissed [1].
>
> Back then, the problem was that as Git wrote files into a directory
> sometimes the clock would tick over at a bad time, and we'd end up
> with some files being "newer" than others.  This would sour Make runs
> as you describe.
>
> Nominally this is caused by putting generated files in the repo, but
> many times that is unavoidable (e.g. you're forking an upstream that 
> puts automake-generated stuff in the repo).
>
> IMHO, dismissing the problem back then was a mistake.  At the time I
> advocated teaching Git to give all the files it touches (creates or 
> modifies) in a directory the same mtime (e.g. the time at the start of
> the checkout operation).
>
> Instead the decision was to do nothing in Git, and instead let people
> create their own post-checkout hooks to touch the files.  I (and
> others) argued this was inadequate, to no avail.
>
> 		M.
>
> [1] https://public-inbox.org/git/20180413170129.15310-1-mgorny@gentoo.org/#r

I think that's the wrong take-away from that thread. Maybe a patch for this will get rejected in the end, but in that case it wasn't because the git project is never going to take a patch like this.

Maybe it won't, but:

 * That commit has no tests
 * It's clearly controversial behavior, so *if* we add it I think it's
   better to make it opt-in configurable.
 * Once that's done, you'd need doc changes etc. for that.

Now, maybe a sufficiently polished version would also be "meh" for whatever reason, I just think it's premature to say that a change in this direction would never be accepted.

That being said, I do wonder if software in the wild is being monkeypatched to work around issues with make (or make-like tools) whether such a change isn't better advocated in e.g. GNU make itself.

If it added "B" to "MAKEFLAGS" if it detected:

 * I'm in a git repository
 * It's the first time I'm running here, or "nothing is built yet"
 * My dependency graph would be different with "-B"

Wouldn't that be what people who want this feature are after?

It's not like it's SCM-agnostic, it already goes to significant trouble to cater to RCS and SCCS of all things, so I don't see why they'd categorically reject a patch to cater to modern VCS's.

And, unlike Gike, GNU make wouldn't need to guess that munging timestamps would fix it, it can compute both versions of the dependency graph, so it would know...