Linus Torvalds, Fri, Jul 25, 2008 04:00:29 +0200:
> 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.
>
But, given the fact, that somewhere sometimes its very-very annoying
to have even one (un)changed file, something must be done about it.
Maybe just direct
# my .gitconfig for Windows machines with GDS
[core]
filemode = false
trustctime = false
logallrefupdates = false
[pack]
threads = 1
etc...
--
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
