Re: Consist timestamps within a checkout/clone

[Marc Branchaud <marcnarc@xiplink.com>]

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