Re: git checkout behaviour when only ctime of file changes

[Cristian Morales Vega <christian.morales.vega@gmail.com>]

On Tue, 20 Apr 2021 at 03:05, brian m. carlson
<sandals@crustytoothpaste.net> 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.