Re: Possible timestamp problems with diff-files?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2011, 21:33 UTC
Message-ID: <7vboud1sz5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E79DF81.8090605@syntevo.com>

Marc Strapetz <marc.strapetz@syntevo.com> writes:

Show 15 quoted lines

> On 20.09.2011 19:54, Jeff King wrote:
>> On Tue, Sep 20, 2011 at 12:30:53PM +0200, Marc Strapetz wrote:
>> 
>>> For our Git client, we are invoking
>>>
>>> git diff-files--quiet --ignore-submodules
>>>
>>> immediately after a commit of *all* changes. Hence, the expected exit
>>> code would be 0 (because there are no changes). A user has now reported
>>> that for commits with many changes, exit code is sometimes 1. For the
>>> last incident, the commit was started at 15:24:11,820 and finished at
>>> 15:24:12,329, diff-files was invoked at 15:24:12,455 and failed with
>>> exit code 1 at 15:24:21,394. A subsequent diff-files succeeded, so I'm
>>> wondering now, if that could be a timestamp problem (maybe related to
>>> the Index)?

What peff said already.

If you do not refresh the cached stat information, diff-files may report "they differ" for a path that is otherwise unchanged without looking at the contents of such a path to notice that the only difference is the cached stat information (the whole and only point of having the cached stat information is to avoid looking at the contents). Also, it may look at the contents of such a path if it has a reason to suspect that the file might have changed if it cannot tell from the cached stat information (look for "racy-git" if you are really interested).

Update the cached stat information before you use plumbing commands in your script.