On Wed, Jan 05, 2011 at 06:07:35AM +0000, Alexander Gladysh wrote: > > Basically, we generate random data which has a 20% chance of > > being the same as what's there. When it is, we should get "not bothering > > to commit", but in your error case, we would try to commit (and get "no > > changes"). > > > But using that script, I can't replicate your problem. Can you try > > running it on the same box you're having trouble with? That might at > > least tell us if it's your environment or something more complex going > > on. > > Thank you. I tried it, and, unfortunately, it does not reproduce the > problem. Oh well, thanks for trying. Going back to your original reproduction recipe, can you change the "diff-index" line to actually report on what it thinks is different? That is, drop the "--quiet" and have it actually produce a patch? It would be interesting to see what is different, and how that compares with the "git status" you run just prior to it (and whether it matches the file you "git add"ed just above). You haven't told us much about your build process. Are you absolutely sure that there couldn't be another process on the system manipulating the files between the various runs? 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). -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