Re: Consist timestamps within a checkout/clone

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Nov 1, 2022, 13:55 UTC
Message-ID: <c060312e-0d35-8439-85dd-920b172c90be@xiplink.com>
In-Reply-To: <2210311614160.25661@stax.localdomain>

On 2022-10-31 15:01, Mark Hills wrote:

Show 12 quoted lines

> 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