From: Junio C Hamano Date: Thu, 08 Nov 2007 20:42:40 GMT Subject: Re: [PATCH 4/3] t3700: avoid racy git situation Message-ID: <7vbqa431vj.fsf@gitster.siamese.dyndns.org> In-Reply-To: Johannes Schindelin writes: > The problem is that the index has the same timestamp as the file "foo". > > Therefore, git cannot tell if "foo" is up-to-date in the index, since it > could have been modified (and indeed is) just a fraction of a second later > than the index was last updated. > > And since diff-index, as called from the test script, does not generate a > diff, but really only determines if the index information suggests that > the files are up-to-date, there is not really much you can do. > > This is our good old friend, the racy git problem. That sounds very wrong. What happened to the ce_smudge_racily_clean_entry() call that is done from write_index()? > NOTE: other scms do not have this problem, mostly because they are too > slow to trigger it. I recall racy-hg mentioned on their development list twice, a few months apart, and CVS has the "delay the return from a commit to the next full second" or something to work around problems in the timestamp recorded in CVS/Entries.