Re: "Racy" GIT

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 24, 2005, 16:34 UTC
Message-ID: <Pine.LNX.4.64.0510240905340.10477@g5.osdl.org>
In-Reply-To: <20051024092952.GZ30889@pasky.or.cz>

On Mon, 24 Oct 2005, Petr Baudis wrote:

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

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