[BUG?] fetching via file:// vs ssh://

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