In message <alpine.LFD.0.999.0708221208090.30176@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Linus Torvalds writes: > > > On Wed, 22 Aug 2007, Erez Zadok wrote: > > > > However, I noticed that after I copy a git repo (using v1.5.2.2), the index > > entries are all out of sync, and I need to run git-reset. Why? What's in > > the index file that changes after a cp -a or rsync that git depends on? Is > > it atime's and if so, aren't they copied by cp -a or rsync? > > ctime/mtime and inode numbers too. > > If you use hardlinks to copy the working tree, *and* you reset ctime > afterwards, you'd be ok. But basically, git tries to be *really* anal in > noticing any possible change to the inode, so anything it can do to notice > that the index file might be stale, it does. > > But you don't need to do a "git reset", you're actually better off just > doing a "git status" instead. That will refresh the index. > > Linus Thanks for the info and tips. It's a good idea of course to detect any possible changes, but I wonder if for those of us who know what they're doing (i.e., living on the edge :-), there could be an option to ignore inode numbers and just depend on good 'ol ctime/mtime (as other tools like make do). If such an option might be deemed useful, I'm willing to take a crack at it. Erez. - 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
