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

From: Chris Packham <judge.packham@gmail.com>
Date: Aug 10, 2012, 01:03 UTC
Message-ID: <CAFOYHZBGuuNY1WqAT_Tk7-ENtSweafuOhf9sw+y6p1Zr4wWxaw@mail.gmail.com>
In-Reply-To: <CAFOYHZAa10Ukya8-Er1rRSKaWW_z+u5cStXNOihVxZqt14qe+A@mail.gmail.com>

(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 <gitster@pobox.com> 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!

Show 72 quoted lines

> On Aug 9, 2012 5:44 PM, "Chris Packham" <judge.packham@gmail.com> wrote:
>>
>> 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