On Wed, 23 Jul 2008, Alex Riesen wrote: > > It is not that it is broken. We just don't need it, because the st_mode > is not used, and the rest of inode information is not used anyway. That is NOT why git checks the ctime. Git checks the ctime not because it cares about the inode state being modified per se: since it can see that _directly_ - so why should it care about inode state like st_mode? No, git checks ctime because it in general tries to make it VERY VERY hard for people to try to "fake out" git and replace files from underneath it without git noticing. It's much easier and much more common for tools to restore 'mtime' when they do some operation on a file than it is for them to restore 'ctime'. For example, if you rsync files between two hosts, the '-t' flag will make rsync try to keep the mtimes in sync (and it's part of '-a', which is the common form that you'd use for rsync). So if you only look at mtime and size, you often miss the fact that the file has actually been messed with! Looking at ctime gets around a number of those things. Of course, it can cause git to be _too_ eager in thinking that a file is modified, and an example of that is the insane indexing that 'beagle' does, which actually modifies the files by adding inode extended attributes to them and thus changes ctime due to the indexing. But in general it's a lot better to be too careful than to miss the fact that somebody changed the file. Linus -- 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
