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@xxxxxxxxxx/#r
