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

(Junio, sorry for the spam. Using the gmail web interface which hides
the reply all option)

On Fri, Aug 10, 2012 at 12:55 PM, Junio C Hamano [off-list ref] wrote:

File:///n/a/b/c and /n/a/b/c behave differently, and the former is more like
ssh://host/n/a/b/c.

So it does.

  $ git remote add -f rmt3 file:///net/path/to/backup/repo
  Updating rmt3
  From file:///net/path/to/backup/repo
   * [new branch]      master     -> rmt3/master

I did try it before sending my original email however I neglected to
put in the third '/' and got a different error, assumed it was the
same as the first. Even better the tab completion works!

On Aug 9, 2012 5:44 PM, "Chris Packham" [off-list ref] wrote:

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html