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

From: Erez Zadok <ezk@cs.sunysb.edu>
Date: Aug 22, 2007, 19:19 UTC
Message-ID: <200708221919.l7MJJNkX012184@agora.fsl.cs.sunysb.edu>
In-Reply-To: <alpine.LFD.0.999.0708221208090.30176@woody.linux-foundation.org>

In message <alpine.LFD.0.999.0708221208090.30176@woody.linux-foundation.org>, Linus Torvalds writes:

Show 20 quoted lines

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