Re: [PATCH 4/3] t3700: avoid racy git situation

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 8, 2007, 20:42 UTC
Message-ID: <7vbqa431vj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0711081511440.4362@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

> 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.