On Wed, Jan 05, 2011 at 07:46:19AM +0000, Alexander Gladysh wrote: > ----> Rebuilding manifest... > Making manifest for . > Generating index.html for . > :100644 100644 483a7292436daecc9bea0ab265ee19d587b14298 > 0000000000000000000000000000000000000000 > M cluster/localhost-ag/rocks/index.html > :100644 100644 fcb9ff896fd1a1bd15663fa9be19b250789d4a25 > 0000000000000000000000000000000000000000 > M cluster/localhost-ag/rocks/manifest > > These are the two files, which are overridden with identical content. > (See below, looks like I realized who to blame.) > > If I read this correctly, Git tells me that the files are deleted. No? No, it just means that the files are stat-dirty with respect to the index. For example: $ git init $ touch file && git add file && git commit -m one $ touch file $ git diff-files :100644 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 M file $ git update-index --refresh $ git diff-files <no output> But in your case, the stat information should be up to date, since you just ran update-index. But see below. > > Are you running on top of any special filesystem that might not meet the > > consistency guarantees we expect (though in that case, I would assume my > > trivial script would have reproduced). > > And here I have to say "Oops". > > My apologies, I should have realized this before: my project is > mounted on VMWare's HGFS. > > (That is: VMWare Fusion Ubuntu Guest -> HGFS -> OS X 10.6 Host files.) > > The problem is not reproduced if I copy the project to the native fs > in the guest machine. > > But the problem is also not reproduced if I execute your script on the HGFS. > > So, does that mean that HGFS violates consistency guarantees? Hmm. That could be the problem. It may not violate traditional consistency guarantees, but I wonder if it is returning slightly different stat information between the program runs. That would mean "git status" does an index refresh and puts some stat information in the index, but the followup "git diff-index" might see different stat information. That's just a theory, though. You might try the patch below: diff --git a/read-cache.c b/read-cache.c index 4f2e890..1b415a3 100644 --- a/read-cache.c +++ b/read-cache.c @@ -283,6 +283,8 @@ int ie_match_stat(const struct index_state *istate, return DATA_CHANGED | TYPE_CHANGED | MODE_CHANGED; changed = ce_match_stat_basic(ce, st); + if (changed) + fprintf(stderr, "changed (%u): %s\n", changed, ce->name); /* * Within 1 second of this sequence: The number in parentheses is the bitwise-or of the things git found that caused the stat information to be stale (the actual flags are the *_CHANGED defines in cache.h, but I was too lazy to write a pretty-printer). If you can get the output from diff-files for the error case, we can at least see why git thinks the cache is stale. -Peff -- 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