Re: git checkout behaviour when only ctime of file changes

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 19, 2021, 20:47 UTC
Message-ID: <xmqqh7k29f35.fsf@gitster.g>
In-Reply-To: <CAOWQn3Qesh0+CkaD95q78Rq_vN5tjWKDe7HTk0Ynk-NY8XUKzg@mail.gmail.com>

Cristian Morales Vega <christian.morales.vega@gmail.com> writes:

Show 6 quoted lines

> 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.

Changes to ctime, not just to mtime, participate in "the path may have been changed so need to go back to the contents to see if it truly has" logic, and "update-index --refresh" is a mechanism to clear that "the path may have been changed" bit.

So if your "behave differently ... with or without refresh" happens equally if you replace 'ctime' in your statement with 'mtime', then everything is working as designed. But it was unclear from your description.

Assuming that the difference with and without refresh after mtime change is the same as the difference with and without refresh after ctime change, the "core.trustctime" configuration variable is for those whose files have untrustworthy ctime (due to background scanners and other funnies).