(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@xxxxxxxxx> 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" <judge.packham@xxxxxxxxx> 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@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html