Re: [PATCH] Build configuration to skip ctime for modification test

> 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.
>