Re: Possible timestamp problems with diff-files?

[Robin Rosenberg <robin.rosenberg@dewire.com>]

Junio C Hamano skrev 2011-09-21 23.33:
> Marc Strapetz<marc.strapetz@syntevo.com>  writes:
>
>> 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.

Using git diff instead of git diff-files would do just that, unless I am
missing something.

-- robin