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