Toralf Förster <toralf.foerster@xxxxxx> writes: > On 12/18/2012 05:41 PM, Jeff King wrote: >> I could reproduce it, too, on Linux. >> >> The reason it does not always happen is that git will not re-examine the >> file content unless the timestamp on the file is older than what's in >> the index. So it is a race condition for git to see whether the file is >> stat-dirty. > > /me still wonders whether this race condition is a feature or an issue > in GIT - b/c it means that 2 different people cloning the same > repository get different results. The primary point of Peff's demonstration was to show that you told your repository to lie to Git, I think. It promised that the contents in the repository was with certain line endings when they are not. At that point Git can do whatever happens when it trusts its behaviour on that broken promise. When the timestamp is set one way, Git happened to be extra careful for other reasons---Git is not in the business of suspecting that the user lied and double checking by wasting cycles [*1*]---and that extra check that does not have anything to do with the end-of-line conversion found that it was lied and noticed differences. That is neither a feature nor a bug. [Footnote] *1* This extra carefulness is to handle the case where *filesystems* lie to Git. The user cannot do anything to make the filesystem not to lie, so we try to be extra careful and examine the contents even when the stat information (incorrectly) says that the file is not modified. Also luckily this happens only to minority of the paths (i.e. you do "git add" and then replace the file with different contents of the same length within the same timestamp granularity, or something like that), so we can afford to. -- 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