Re: "Racy" GIT

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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html