Concurrent modification breaks "racy git"

I found a case in which git fails to notice a modification to a file in the working tree if the modification is concurrent with git-add. The script below demonstrates it:

-----------

#!/bin/bash set -x

rm -rf test mkdir test cd test

git-init-db
perl -e 'foreach $i (1...100) { open F, ">foo$i";
                truncate F, 5000000; close F; }'

echo data1 >bar # Write bar... git-add bar foo* & sleep .1 # give git-add time to add it... echo data2 >bar # and change it again in the same second!

# git-add takes a while to read foo*, so the index file gets a # later timestamp, so git doesn't realize that bar's cleanliness # is racy. wait

git-diff bar # Now you don't see the difference...

touch bar git-diff bar # Now you do!

-----------

I doubt this case will happen to anyone in practice, but I at least wanted to make sure people knew about it. To fix it, git-add could use a timestamp taken just before it starts reading files in place of the mtime of the index.

Matt