On Tue, 20 Apr 2021 at 03:05, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2021-04-19 at 09:11:12, Cristian Morales Vega wrote: > > I thought you may want to take a look at > > https://issues.jenkins.io/browse/JENKINS-65395. > > > > Basically after something updates the ctime of a file, a > > "git checkout" can behave differently depending on whether a > > "git update-index --refresh" has been run before or not. > > _Maybe_ it could make sense for "git checkout" to always behave as if > > "git update-index --refresh" had been run before? No idea really. > > I believe the situation you're seeing is that git checkout usually > doesn't rewrite files in the working tree that are already up to date. > This makes checkout much faster in large working trees. > > By default, Git does include the ctime in its computation of whether a > file is up to date. If the ctime changes, then the file is considered > to be stale. git checkout, without an intervening command, will > overwrite it, since it's dirty and just overwriting it is cheaper than > determining whether it is in fact up to date. Yes, this is basically it. The "just overwriting it is cheaper than determining whether it is in fact up to date" is the main thing. I was thinking that maybe, if ctime has changed but mtime hasn't, it could be faster to not overwrite the files since I _think_ it means the file contents don't need to be checked, only the basic file permissions (I don't think git stores any extended attributes, does it?). But I could be completely wrong here. Otherwise "core.trustctime" seems like the perfect option for the problem.
