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)? > > diff-files is scriptable plumbing, which means it is up to the script > writer to decide exactly when the index should be refreshed with respect > to the working tree files (because doing so could be kind of expensive, > as it needs to stat every file in the working tree). Have you tried > running "git update-index --refresh" just before your diff-files? My point is that "git diff-files --quiet" seems to returns 1 and when invoked a short time later (without modifying working tree or invoking any other Git command) it returns 0. This would indicate a bug in Git, I guess. I think we can add more debug logging to our client to track down that problem. However, to do that I'd need some input on what to log? -- Best regards, Marc Strapetz ============= syntevo GmbH http://www.syntevo.com http://blog.syntevo.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html