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

[Linus Torvalds <torvalds@linux-foundation.org>]

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