From: Robin Rosenberg Date: Sat, 24 Sep 2011 14:30:56 GMT Subject: Re: Possible timestamp problems with diff-files? Message-ID: <4E7DE9A0.8070209@dewire.com> In-Reply-To: <7vboud1sz5.fsf@alter.siamese.dyndns.org> Junio C Hamano skrev 2011-09-21 23.33: > Marc Strapetz 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