Re: git bugs

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2008, 23:38 UTC
Message-ID: <7v1w34dfn3.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <832adb090806101609q17a21948nb5814c3b22bd832d@mail.gmail.com>

"Ben Lynn" <benlynn@gmail.com> writes:

> I had thought about this. I hacked some code up where the index looks
> at the current system time when updating a cache entry to determine if
> the hash is racy. Is doing one time(NULL) call per file reasonable?
> I'm guessing it must be cheaper that a stat call.

Hmm, sorry, could you elaborate how you would plan to use the return value from time(2) per file?

The "index file timestamp" trick assumes that once we start reading from and writing to the filesystem (in order to hash the current contents, check if there is any modification), nobody else touches the paths we are interested in (e.g., after "read-tree -m -u" checks out the new contents, grabs the stat information from the newly deposited file and stuffs that in the index, you do not go in and edit it further until our process returns the control to you). We also assume that the files (both work tree and the index) live in the same filesystem and the file timestamp, which could be skewed compared to the system clock if the filesystem is over the network, are consistent among them and monotonicly increasing.

        You have to have some assumption --- if you allow anybody to touch
        anything behind your back, or if you allow timestamps of some
        files come from different time sources than the one for some other
        files, I do not think any lstat(2) based change detection scheme
        would work.

We do our writeout first and then the index is updated after all our writeout is done, so by definition (more precisely, "by that assumption"), anything older than the timestamp of the index file are up to date, if their filesystem timestamp match the timestamp recorded in the index, and anything that is the same or newer than the index timestamp is suspect.

And that is the reason the current code gets by only with a single timestamp. I'd have to go back and study your breakage scenario a bit better (I'm still at work today).