Nicolas Pitre wrote: > On Thu, 18 Feb 2010, Junio C Hamano wrote: >> I suspect that opening to mmap(2), hashing once to compute the object >> name, and deflating it to write it out, will all happen within the same >> second, unless you are talking about a really huge file, or you started at >> very near a second boundary. > > How is the index dealing with this? Surely if a file is added to the > index and modified within the same second then 'git status' will fail to > notice the changes. I'm not familiar enough with that part of Git. See Documentation/technical/racy-git.txt and t/t0010-racy-git.sh. Short version: in the awful case, the timestamp of the index is the same as (or before) the timestamp of the file. Git will notice this and re-hash the tracked file. > Alternatively, you could use the initial mtime sample to determine the > filesystem's time granularity by noticing how many LSBs are zero. Yuck. If such detection is going to happen, I would prefer to see it used once to determine the initial value of a per-repository configuration variable asking to speed up ‘git add’ and friends. Note that we are currently not using the nsec timestamps to make any important decisions, probably because in some filesystems they are unreliable when inode cache entries are evicted (not sure about the current status; does this work in NFS, for example?). Within the short runtime of ‘git add’, I guess this would not be as much of a problem. Jonathan -- 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