Cloning local repos with relative paths does not work

[fingolfin]

Suppose I have a repository "git-repo". Cloning this locally with a relative path like this

  git clone git-repo git-clone

works fine; git resolves the relative path and my .git/config ends up contains a full path, so that e.g. "git pull" later on works.

This is not the case when I use remote-hg:

$ git clone hg::hg-repo hg-clone
Cloning into 'hg-clone'...
$ cd hg-clone
$ git pull
Traceback (most recent call last):
[...]
mercurial.error.RepoError: repository hg-repo not found
$

Not a terrible problem (I can just use a full path), but inconvenient; would be nice if this could be fixed.

[felipec]

You need to do $PWD/git-repo. Relative paths not working is a limitation of the git remote infrastructure, you need to report that to upstream; to the git mailing list.

[fingolfin]

Hm, really? But the part of the "URL" after hg:: is completely opaque to git; it cannot know what it is: a path, a URL, some other kind of description of a local or remote repository. So the remoter helper must resolve it, git cannot do it.

And indeed it can do that, by replicating what the git clone command does in get_repo_path().

This only leaves us to tell git about the "resolved" path, which we can do by invoking "git config". The following snippet, inserted at the start of the main function (around line 727) does the job for me:

    if os.path.isdir(url):
        abs_path = os.path.abspath(url)
        if abs_path != url:
            cmd = ['git', 'config', 'remote.%s.url' % alias, "hg::" + abs_path]
            subprocess.call(cmd)
            url = abs_path

Perhaps there is a better way, though, and perhaps this use of "git config" is bad for other reasons, but it certainly seems possible to fix this from a remote-helper :-). Perhaps some added logic in git.git would make it easier, though, although the above isn't very complicated?

Of course one might want to make better checks than just os.path.isdir(), perform error handling, add test cases, and make sure this doesn't break other kinds of URLs...

[felipec]

Yes, the remote helper must resolve it, but it should communicate it back to git, and let git do it. Doing it in the remote helper smells like an ugly hack.

What happens if git stores the remote url after calling the transport helper? It doesn't do it now, but it might do so in the future.

However, the current situation is not nice, better have a hack and the proper fix later than nothing at all; let not the perfect be the enemy of the good.

Looks good to me.

[felipec]

I tried that code, but it doesn't handle certain subtleties such as an URL like 'file:dir', or fake urls for testing like 'remote://$PWD/dir' (which admittedly are not being used right now).

I think a more generic solution that uses the actual repo url as converted by hg would be safer:

--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -720,6 +720,14 @@ def do_export(parser):
     if peer:
         parser.repo.push(peer, force=False)

+def fix_path(alias, repo, orig_url):
+    repo_url = util.url(repo.url())
+    url = util.url(orig_url)
+    if str(url) == str(repo_url):
+        return
+    cmd = ['git', 'config', 'remote.%s.url' % alias, "hg::%s" % repo_url]
+    subprocess.call(cmd)
+
 def main(args):
     global prefix, dirname, branches, bmarks
     global marks, blob_marks, parsed_refs
@@ -766,6 +774,9 @@ def main(args):
     repo = get_repo(url, alias)
     prefix = 'refs/hg/%s' % alias

+    if not is_tmp:
+        fix_path(alias, peer or repo, url)
+
     if not os.path.exists(dirname):
         os.makedirs(dirname)

[felipec]

Pushed, please verify that it works.

[fingolfin]

So far, your change seems to work fine, thanks!

I do agree that setting remote.origin.url like that is a hack, but at least it works for now, which is very nice :). But I also sent a message to the git ML asking for alternatives.

[felipec]

Cool. I read your mail to git ml, I was planning to do the same. Thanks.