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.

        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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to