Re: git bugs

Ah, I hadn't seen that. Yes, it is better to use the first write as
the timestamp. Would this catch everything? If the filesystem clock is
monotonically increasing and consistent then with this setup, you can
touch files even as they are being indexed? (Disregarding nonsense
like changing sizes by 2^32.)

Just realized I should have paid more attention to Junio's first reply
to me. My eye had skipped over the paragraph about clock skew, and
this caused some confusion. Sorry about all my extra emails!

-Ben

On Tue, Jun 10, 2008 at 7:12 PM, Linus Torvalds
[off-list ref] wrote:

On Tue, 10 Jun 2008, Ben Lynn wrote:

quoted

Sorry, but if we're assuming no one is touching the files while we're
updating the index (including writing it to disk), why does it matter
whether we use the time of first or last write? In fact, if a index
write takes a long time, using the last write time as the mtime would
be beneficial for the race condition stuff.

Oh, if you assume nobody is touching the files as the index is created,
none of this matters.

So if *that* was your only race worry, then git should already be
perfectly fine.

The issue with the timestamp of the index only happens if somebody ends up
modifying the files that are being indexed _as_ they are indexed. Quite
frankly, git will notice that too in just about all possible cases, but if
the size stays the same and the modification time ends up still being
smaller than the final index mtime (because writing the index took so
long!), then you might miss some modifications that would otherwise be
noticed.

               Linus