{"thread":{"id":"32176","subject":"remote helper and relative local paths","startedAt":"2012-11-23T11:02:04Z","lastAt":"2012-11-23T11:02:04Z","messageCount":1,"participants":["Max Horn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203694","messageId":"605DC086-713B-4986-B1C0-BD2EFF1D636B@quendi.de","threadId":"32176","inReplyTo":null,"subject":"remote helper and relative local paths","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2012-11-23T11:02:04Z","receivedAt":"2012-11-23T11:02:04Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"I noticed a problem with remote helpers which is mainly about convenience, but still annoying enough that I wish it could be resolved; but I'd like some input on what the proper way would be...\n\nHere is the issue: cloning with relative paths is problematic (if not broken) when using remote-helpers, unless one is willing to dive into some (IMHO) gross hacking... To demonstrate what I mean, first consider that cloning a local git repo using relative paths works fine: If the parent dir contains a git repository \"git-repo\", this works:\n\n  $ git clone ../git-repo git-clone\n  Cloning into 'git-clone'...\n  done.\n  $ cd git-clone && git pull\n  Current branch master is up to date.\n  $\n\nBut when doing the same with a remote helper, it doesn't work; or rather, the initial cloning might work, but we end up with a broken remote.origin.url, as that still contains the relative path, but it no longer can be resolved since the PWD changed. E.g. here is an example using felipe's remote-hg:\n\n  $ git clone hg::../hg-repo git-clone\n  Cloning into 'git-clone'...\n  $ cd git-clone && git pull\n  Traceback (most recent call last):\n  [...]\n  mercurial.error.RepoError: repository ../hg-repo not found\n  $\n\n\nOne problem here is that git cannot resolve the local path in \"hg::../hg-repo\", because this URL is opaque for git, it's a black-box. Hence the code in \"git clone\" that would normally take care of this (specifically, get_repo_path() in builtin/clone.c) does not get applied.\n\nNow, it is not difficult to resolve a relative path, and so a remote helper can do this -- but we only can do this while cloning (and then have to store the absolute path / the new URL), because later on, crucial information (the PWD at the time of cloning) is not available anymore.\n\n\nSo I made a hack that does this: In the remote helper, if the URL looks like a local path, and points to a directory containing a .hg subdir (or some variation of that), translate it into an absolute path. Then (and that is the part I feel bad about) invoke\n  git config remote.REPOS_ALIAS.url hg::the_computed_absolute_path\n\nThis works, but feels like a gross hack to me. In particular, as Felipe pointed out to me: While git is setting the remote.origin.url before invoking the remote helper right now, there is no guarantee for that (at least none that I am aware of). \n\nSo, is there a better way to achieve this that I am overlooking? Or does what I am doing actually seem fine? Or should there be a change to git itself (e.g. a revision to the remote-helper protocol) that helps to take care of that? And how should that look?\n\nOne simple idea for the last option would be to add a \"sanitize\" capability to remote-helpers, which takes a repository URL, and returns a sanitized version, where e.g. local paths have been resolved, and then \"git clone\" would make use of that to set the remote URL right. But perhaps I am overcomplicating things?\n\n\nCheers,\nMax"}]}