# why git-reset needed after "cp -a" of a git repo? 5 messages from 2007-08-22 to 2007-08-22. Participants: Erez Zadok, Jon Loeliger, Linus Torvalds, J. Bruce Fields. Thread: https://gitlist.dev/t/9614 ## Erez Zadok, 2007-08-22 18:57 Subject: why git-reset needed after "cp -a" of a git repo? Message-ID: <200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu> URL: https://gitlist.dev/e/200708221857.l7MIv5tD011053%40agora.fsl.cs.sunysb.edu ``` Apologies if this had been discussed before: I wasn't able to find this in the ML archives. Sometimes I copy a whole git archive using cp -a, for experimental reasons, or otherwise; sometimes I rsync several git repos between remote and local computers to make access faster (it's often faster to rsync two git repos than to re-clone or deal with merge conflicts). 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? If it depends on atime's, what happens if I mount my filesystem with noatime? Or does git's index depends on inode numbers which change after a cp -a? (BTW, I tried a variety of rsync options and none helped.) I also briefly looked at the source code and wasn't able to find the answer. So, is there a way to efficiently copy a git repo on a local or remote host w/o having to rerun git-reset afterwards? Thanks, Erez. ``` ## Jon Loeliger, 2007-08-22 19:04 Subject: Re: why git-reset needed after "cp -a" of a git repo? Message-ID: <1187809479.15321.15.camel@ld0161-tx32> URL: https://gitlist.dev/e/1187809479.15321.15.camel%40ld0161-tx32 In-Reply-To: <200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu> ``` On Wed, 2007-08-22 at 13:57, 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? If it depends > on atime's, what happens if I mount my filesystem with noatime? Or does > git's index depends on inode numbers which change after a cp -a? (BTW, I > tried a variety of rsync options and none helped.) I also briefly looked at > the source code and wasn't able to find the answer. > > So, is there a way to efficiently copy a git repo on a local or remote host > w/o having to rerun git-reset afterwards? Use "git update-index --refresh" to update time stamps in the index. jdl ``` ## Linus Torvalds, 2007-08-22 19:11 Subject: Re: why git-reset needed after "cp -a" of a git repo? Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0708221208090.30176%40woody.linux-foundation.org In-Reply-To: <200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu> ``` 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 ``` ## Erez Zadok, 2007-08-22 19:19 Subject: Re: why git-reset needed after "cp -a" of a git repo? Message-ID: <200708221919.l7MJJNkX012184@agora.fsl.cs.sunysb.edu> URL: https://gitlist.dev/e/200708221919.l7MJJNkX012184%40agora.fsl.cs.sunysb.edu In-Reply-To: ``` In message , 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. ``` ## J. Bruce Fields, 2007-08-22 20:14 Subject: Re: why git-reset needed after "cp -a" of a git repo? Message-ID: <20070822201435.GK20946@fieldses.org> URL: https://gitlist.dev/e/20070822201435.GK20946%40fieldses.org In-Reply-To: <200708221919.l7MJJNkX012184@agora.fsl.cs.sunysb.edu> ``` 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. ```