"Racy" GIT

  Hello,

  I've  thought that I might describe the race I've hit the last night
here so that if you meet it too, you will have an idea what is going on
and won't waste your time debugging it, like I did. ;-)

  What did I do:

  echo v1 >file
  cg-add file
  cg-commit -m"v1"

  echo v2 >file
  cg-commit -m"v2"

  Guess what - the second cg-commit didn't commit the new version of the
file. git-diff-index didn't show anything. GIT just didn't care about
the change.

  Obviously, the problem was that the stat information was exactly the
same after the change (it was in a script, so no ctime change, and the
size was the same as well). The solution is to tell git/Cogito about the
change explicitly (in Cogito, you can do that e.g. by calling cg-add on
the file again). This can be obviously very confusing (and dangerous),
but if we want to keep the stat caching, I guess there is no way around
this (except for sub-second ctimes, but that effectively killed the stat
caching on the filesystems which didn't support it).

On Mon, 24 Oct 2005, Petr Baudis wrote:

Yeah. This is why I wanted to use the "tv_nsec" field originally.

As it is, if you change a file within a second so that the length is the same (and inode stays the same), the stat cache can't help you.

Now, this will only trigger if you do a git-update-index (either directly or like in your example, indirectly though doing a commit that does it) and then change it again immediately, so in practice it shouldn't matter. Except for scripts.

In scripts, you can avoid this certain ways:

 - add a "sleep 1" (gaah, just joking, but it works)

 - use "git-apply --index" (which updates the index on its own on any 
   files it changes) to apply any patches.

 - use an explicit "git-update-index -- filename"

 - if you actually change the inode number, it should be ok, ie

	sed script < a > b && mv b a

   will change the inode number, and that should trigger the index tests 
   too. NOTE!! This isn't guaranteed, especially if you do it twice (it 
   might re-use the original one)

Note that "git-update-index --refresh" will _not_ work, since it looks if it changed. But an explicit filename will force an update if you know it changed.

And yes, I guess we should document this in big letters.

(There _are_ actually tricks you can do to make this usually less of an issue:

 - if the git-update-cache --refresh finds file where the mtime matches 
   the current date. It sets a flag. At the end, it waits for the next 
   second to roll around before returning.

might work well enough)

		Linus