On Fri, Feb 19, 2010 at 09:52:10AM -0800, Junio C Hamano wrote: > As you may have realized, racy-git solution actually _relies_ on lack of > concurrent modifications. It relies on 1) no concurrent modifications, 2) strictly increasing timestamps, and 3) consistent timestamps between the working directory and index. Believe it or not, out of those three I actually think the first assumption is the most reasonable, because it's something a user could prevent without using administrative privileges or changing filesystems. For performance reasons I frequently work with GIT_DIR on ext3 and working directory on tmpfs (though a mix of ext3 and ext4 has the same issues). One has second resolution, the other nanosecond. If two event timestamps with different precisions are compared as values at maximum precision, the later event might appear to occur before the earlier one. I try to avoid using anything that relies on mtime on network filesystems because a lot more than just Git breaks in those cases. NTP breakage is rarer, mostly because NTP step events are rare, and negative ones ever rarer. I've seen negative steps on laptops when they lose time accuracy during suspend or when Internet access is unavailable (or asymmetrically laggy), then get it back later. On the other hand, I don't actually test for effects of this event anywhere, so I can't say it hasn't caused breakage I don't know about, although I can say it hasn't cause breakage I do know about either. -- 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