Subject: Re: git checkout behaviour when only ctime of file changes

From: "brian m. carlson" <[email-masked]>
Date: Tue, 20 Apr 2021 02:04:52 +0000

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.

git update-index --refresh does the check about whether the file is in
fact up to date.  This isn't free; if you've modified 1000 files, or if
you've modified large files, there's going to be a cost to this, and it
can be very substantial.  As mentioned, git checkout doesn't want to
perform that cost needlessly, so it overwrites the file unconditionally.

As far as I'm aware, Git doesn't document which files it does and does
not rewrite in the working tree as part of a checkout, except as part of
certain specified options (e.g., the --overlay option).  It is therefore
free to choose any algorithm it chooses, and in this case, we've
optimized for checkout performance, not minimal modifications.

There is a config option, core.trustctime, which can be set to false if
you don't want to consider the ctime as part of whether a file is up to
date.  But Git is behaving correctly and as desired here.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US