Concurrent modification breaks "racy git"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux