Re: why git-reset needed after "cp -a" of a git repo?

In message [off-list ref], Linus Torvalds writes:

On Wed, 22 Aug 2007, Erez Zadok wrote:

quoted

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.

On Wed, Aug 22, 2007 at 03:19:23PM -0400, Erez Zadok wrote:

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

I don't think there's any need for that.  You can always just run
git-update-index --refresh or just git-status to refresh the stat data
that's kept in the index.  That miscellaneous stat data (ctime, mtime,
inode number) is just there as an optimization, so git-diff doesn't have
to read every file.  It can be tossed out and regenerated any time.

--b.