{"thread":{"id":"9614","subject":"why git-reset needed after \"cp -a\" of a git repo?","startedAt":"2007-08-22T18:57:05Z","lastAt":"2007-08-22T20:14:35Z","messageCount":5,"participants":["Erez Zadok","Jon Loeliger","Linus Torvalds","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51276","messageId":"200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu","threadId":"9614","inReplyTo":null,"subject":"why git-reset needed after \"cp -a\" of a git repo?","fromName":"Erez Zadok","fromEmail":"ezk@cs.sunysb.edu","sentAt":"2007-08-22T18:57:05Z","receivedAt":"2007-08-22T18:57:05Z","isPatch":false,"sender":{"key":"ezk@cs.sunysb.edu","avatar":null},"body":"Apologies if this had been discussed before: I wasn't able to find this in\nthe ML archives.\n\nSometimes I copy a whole git archive using cp -a, for experimental reasons,\nor otherwise; sometimes I rsync several git repos between remote and local\ncomputers to make access faster (it's often faster to rsync two git repos\nthan to re-clone or deal with merge conflicts).\n\nHowever, I noticed that after I copy a git repo (using v1.5.2.2), the index\nentries are all out of sync, and I need to run git-reset. Why? What's in\nthe index file that changes after a cp -a or rsync that git depends on? Is\nit atime's and if so, aren't they copied by cp -a or rsync? If it depends\non atime's, what happens if I mount my filesystem with noatime? Or does\ngit's index depends on inode numbers which change after a cp -a? (BTW, I\ntried a variety of rsync options and none helped.) I also briefly looked at\nthe source code and wasn't able to find the answer.\n\nSo, is there a way to efficiently copy a git repo on a local or remote host\nw/o having to rerun git-reset afterwards?\n\nThanks,\nErez.\n"},{"id":"51277","messageId":"1187809479.15321.15.camel@ld0161-tx32","threadId":"9614","inReplyTo":"200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu","subject":"Re: why git-reset needed after \"cp -a\" of a git repo?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-08-22T19:04:39Z","receivedAt":"2007-08-22T19:04:39Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Wed, 2007-08-22 at 13:57, Erez Zadok wrote:\n\n> However, I noticed that after I copy a git repo (using v1.5.2.2), the index\n> entries are all out of sync, and I need to run git-reset. Why? What's in\n> the index file that changes after a cp -a or rsync that git depends on? Is\n> it atime's and if so, aren't they copied by cp -a or rsync? If it depends\n> on atime's, what happens if I mount my filesystem with noatime? Or does\n> git's index depends on inode numbers which change after a cp -a? (BTW, I\n> tried a variety of rsync options and none helped.) I also briefly looked at\n> the source code and wasn't able to find the answer.\n> \n> So, is there a way to efficiently copy a git repo on a local or remote host\n> w/o having to rerun git-reset afterwards?\n\n\nUse \"git update-index --refresh\" to update time stamps in the index.\n\njdl\n"},{"id":"51279","messageId":"alpine.LFD.0.999.0708221208090.30176@woody.linux-foundation.org","threadId":"9614","inReplyTo":"200708221857.l7MIv5tD011053@agora.fsl.cs.sunysb.edu","subject":"Re: why git-reset needed after \"cp -a\" of a git repo?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-22T19:11:14Z","receivedAt":"2007-08-22T19:11:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Aug 2007, Erez Zadok wrote:\n> \n> However, I noticed that after I copy a git repo (using v1.5.2.2), the index\n> entries are all out of sync, and I need to run git-reset. Why? What's in\n> the index file that changes after a cp -a or rsync that git depends on? Is\n> it atime's and if so, aren't they copied by cp -a or rsync?\n\nctime/mtime and inode numbers too.\n\nIf you use hardlinks to copy the working tree, *and* you reset ctime \nafterwards, you'd be ok. But basically, git tries to be *really* anal in \nnoticing any possible change to the inode, so anything it can do to notice \nthat the index file might be stale, it does.\n\nBut you don't need to do a \"git reset\", you're actually better off just \ndoing a \"git status\" instead. That will refresh the index.\n\n\t\tLinus\n"},{"id":"51281","messageId":"200708221919.l7MJJNkX012184@agora.fsl.cs.sunysb.edu","threadId":"9614","inReplyTo":"alpine.LFD.0.999.0708221208090.30176@woody.linux-foundation.org","subject":"Re: why git-reset needed after \"cp -a\" of a git repo?","fromName":"Erez Zadok","fromEmail":"ezk@cs.sunysb.edu","sentAt":"2007-08-22T19:19:23Z","receivedAt":"2007-08-22T19:19:23Z","isPatch":false,"sender":{"key":"ezk@cs.sunysb.edu","avatar":null},"body":"In message , Linus Torvalds writes:\n> \n> \n> On Wed, 22 Aug 2007, Erez Zadok wrote:\n> > \n> > However, I noticed that after I copy a git repo (using v1.5.2.2), the index\n> > entries are all out of sync, and I need to run git-reset. Why? What's in\n> > the index file that changes after a cp -a or rsync that git depends on? Is\n> > it atime's and if so, aren't they copied by cp -a or rsync?\n> \n> ctime/mtime and inode numbers too.\n> \n> If you use hardlinks to copy the working tree, *and* you reset ctime \n> afterwards, you'd be ok. But basically, git tries to be *really* anal in \n> noticing any possible change to the inode, so anything it can do to notice \n> that the index file might be stale, it does.\n> \n> But you don't need to do a \"git reset\", you're actually better off just \n> doing a \"git status\" instead. That will refresh the index.\n> \n> \t\tLinus\n\nThanks for the info and tips. It's a good idea of course to detect any\npossible changes, but I wonder if for those of us who know what they're\ndoing (i.e., living on the edge :-), there could be an option to ignore\ninode numbers and just depend on good 'ol ctime/mtime (as other tools like\nmake do).\n\nIf such an option might be deemed useful, I'm willing to take a crack at it.\n\nErez.\n"},{"id":"51286","messageId":"20070822201435.GK20946@fieldses.org","threadId":"9614","inReplyTo":"200708221919.l7MJJNkX012184@agora.fsl.cs.sunysb.edu","subject":"Re: why git-reset needed after \"cp -a\" of a git repo?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-22T20:14:35Z","receivedAt":"2007-08-22T20:14:35Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Aug 22, 2007 at 03:19:23PM -0400, Erez Zadok wrote:\n> Thanks for the info and tips. It's a good idea of course to detect any\n> possible changes, but I wonder if for those of us who know what they're\n> doing (i.e., living on the edge :-), there could be an option to ignore\n> inode numbers and just depend on good 'ol ctime/mtime (as other tools like\n> make do).\n\nI don't think there's any need for that. You can always just run\ngit-update-index --refresh or just git-status to refresh the stat data\nthat's kept in the index. That miscellaneous stat data (ctime, mtime,\ninode number) is just there as an optimization, so git-diff doesn't have\nto read every file. It can be tossed out and regenerated any time.\n\n--b.\n"}]}