{"thread":{"id":"31222","subject":"[BUG?] fetching via file:// vs ssh://","startedAt":"2012-08-10T00:43:02Z","lastAt":"2012-08-10T01:03:53Z","messageCount":2,"participants":["Chris Packham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196768","messageId":"CAFOYHZBm7uOHtDhBJaMO9=u4BEsbLdhPUAHra6Pyd9TGONAa3Q@mail.gmail.com","threadId":"31222","inReplyTo":null,"subject":"[BUG?] fetching via file:// vs ssh://","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2012-08-10T00:43:02Z","receivedAt":"2012-08-10T00:43:02Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nAt $dayjob we have backups setup for developers using a post-commit\nhook that rsyncs the local .git directory to a backup server. The\nadvantage we get of using rsync instead of git push is that we also\nbackup the things that git push doesn't touch (e.g. config, hooks,\nmetadata from other tools). A happy side effect of this method is that\nwhen we want to share code people can just fetch it from backup server\nvia nfs.\n\nThis is where my current problem lies. On a plain repository I can simply run\n\n  $ git remote add -f rmt /net/path/to/backup/repo\n\nHowever on a repository that is a submodule with a relocated .git\ndirectory I get the following\n\n  $ git --version\n  git version 1.7.12.rc2.16.g034161a\n\n  $ git remote add -f rmt /net/path/to/backup/repo\n  Updating rmt\n  remote: fatal: Could not chdir to '../../../repo': No such file or directory\n  error: git upload-pack: git-pack-objects died with error.\n  fatal: git upload-pack: aborting due to possible repository\ncorruption on the remote side.\n  remote: aborting due to possible repository corruption on the remote side.\n  fatal: protocol error: bad pack header\n  error: Could not fetch rmt\n\nLooking at /net/path/to/backup/repo/config I can guess what the\nproblem is, however I wouldn't have thought that git fetch would even\ncare about the worktree configuration.\n\n  [core]\n        repositoryformatversion = 0\n        filemode = true\n        bare = false\n        logallrefupdates = true\n        worktree = ../../../repo\n\nUsing ssh:// instead of file:// works as expected\n\n  $ git remote add -f rmt2 ssh://server/path/to/backup/repo\n  Updating rmt2\n  remote: Counting objects: 10, done.\n  remote: Compressing objects: 100% (5/5), done.\n  remote: Total 6 (delta 3), reused 0 (delta 0)\n  Unpacking objects: 100% (6/6), done.\n  From ssh://server/path/to/backup/repo\n   * [new branch]      master     -> rmt2/master\n\nUsing ssh is a viable workaround but plenty of people here have\nthought their fingers /net/server/user<tab> (which also let's you\ncheck the path for validity along the way).\n\nIs there any reason fetching using file:// should care about the\nremote's worktree? The version of git on the server is different (git\nversion 1.7.1) so it could be a bug in fetch that is not exposed when\ncloning via ssh.\n\nThanks,\nChris\n"},{"id":"196769","messageId":"CAFOYHZBGuuNY1WqAT_Tk7-ENtSweafuOhf9sw+y6p1Zr4wWxaw@mail.gmail.com","threadId":"31222","inReplyTo":"CAFOYHZAa10Ukya8-Er1rRSKaWW_z+u5cStXNOihVxZqt14qe+A@mail.gmail.com","subject":"Fwd: [BUG?] fetching via file:// vs ssh://","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2012-08-10T01:03:53Z","receivedAt":"2012-08-10T01:03:53Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"(Junio, sorry for the spam. Using the gmail web interface which hides\nthe reply all option)\n\nOn Fri, Aug 10, 2012 at 12:55 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> File:///n/a/b/c and /n/a/b/c behave differently, and the former is more like\n> ssh://host/n/a/b/c.\n\nSo it does.\n\n  $ git remote add -f rmt3 file:///net/path/to/backup/repo\n  Updating rmt3\n  From file:///net/path/to/backup/repo\n   * [new branch]      master     -> rmt3/master\n\nI did try it before sending my original email however I neglected to\nput in the third '/' and got a different error, assumed it was the\nsame as the first. Even better the tab completion works!\n\n> On Aug 9, 2012 5:44 PM, \"Chris Packham\" <judge.packham@gmail.com> wrote:\n>>\n>> Hi,\n>>\n>> At $dayjob we have backups setup for developers using a post-commit\n>> hook that rsyncs the local .git directory to a backup server. The\n>> advantage we get of using rsync instead of git push is that we also\n>> backup the things that git push doesn't touch (e.g. config, hooks,\n>> metadata from other tools). A happy side effect of this method is that\n>> when we want to share code people can just fetch it from backup server\n>> via nfs.\n>>\n>> This is where my current problem lies. On a plain repository I can simply\n>> run\n>>\n>>   $ git remote add -f rmt /net/path/to/backup/repo\n>>\n>> However on a repository that is a submodule with a relocated .git\n>> directory I get the following\n>>\n>>   $ git --version\n>>   git version 1.7.12.rc2.16.g034161a\n>>\n>>   $ git remote add -f rmt /net/path/to/backup/repo\n>>   Updating rmt\n>>   remote: fatal: Could not chdir to '../../../repo': No such file or\n>> directory\n>>   error: git upload-pack: git-pack-objects died with error.\n>>   fatal: git upload-pack: aborting due to possible repository\n>> corruption on the remote side.\n>>   remote: aborting due to possible repository corruption on the remote\n>> side.\n>>   fatal: protocol error: bad pack header\n>>   error: Could not fetch rmt\n>>\n>> Looking at /net/path/to/backup/repo/config I can guess what the\n>> problem is, however I wouldn't have thought that git fetch would even\n>> care about the worktree configuration.\n>>\n>>   [core]\n>>         repositoryformatversion = 0\n>>         filemode = true\n>>         bare = false\n>>         logallrefupdates = true\n>>         worktree = ../../../repo\n>>\n>> Using ssh:// instead of file:// works as expected\n>>\n>>   $ git remote add -f rmt2 ssh://server/path/to/backup/repo\n>>   Updating rmt2\n>>   remote: Counting objects: 10, done.\n>>   remote: Compressing objects: 100% (5/5), done.\n>>   remote: Total 6 (delta 3), reused 0 (delta 0)\n>>   Unpacking objects: 100% (6/6), done.\n>>   From ssh://server/path/to/backup/repo\n>>    * [new branch]      master     -> rmt2/master\n>>\n>> Using ssh is a viable workaround but plenty of people here have\n>> thought their fingers /net/server/user<tab> (which also let's you\n>> check the path for validity along the way).\n>>\n>> Is there any reason fetching using file:// should care about the\n>> remote's worktree? The version of git on the server is different (git\n>> version 1.7.1) so it could be a bug in fetch that is not exposed when\n>> cloning via ssh.\n>>\n>> Thanks,\n>> Chris\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}