Hi,
At $dayjob we have backups setup for developers using a post-commit
hook that rsyncs the local .git directory to a backup server. The
advantage we get of using rsync instead of git push is that we also
backup the things that git push doesn't touch (e.g. config, hooks,
metadata from other tools). A happy side effect of this method is that
when we want to share code people can just fetch it from backup server
via nfs.
This is where my current problem lies. On a plain repository I can simply run
$ git remote add -f rmt /net/path/to/backup/repo
However on a repository that is a submodule with a relocated .git
directory I get the following
$ git --version
git version 1.7.12.rc2.16.g034161a
$ git remote add -f rmt /net/path/to/backup/repo
Updating rmt
remote: fatal: Could not chdir to '../../../repo': No such file or directory
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository
corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
error: Could not fetch rmt
Looking at /net/path/to/backup/repo/config I can guess what the
problem is, however I wouldn't have thought that git fetch would even
care about the worktree configuration.
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = ../../../repo
Using ssh:// instead of file:// works as expected
$ git remote add -f rmt2 ssh://server/path/to/backup/repo
Updating rmt2
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 6 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From ssh://server/path/to/backup/repo
* [new branch] master -> rmt2/master
Using ssh is a viable workaround but plenty of people here have
thought their fingers /net/server/user<tab> (which also let's you
check the path for validity along the way).
Is there any reason fetching using file:// should care about the
remote's worktree? The version of git on the server is different (git
version 1.7.1) so it could be a bug in fetch that is not exposed when
cloning via ssh.
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html