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