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...

Here 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:

  $ git clone ../git-repo git-clone
  Cloning into 'git-clone'...
  $ cd git-clone && git pull
  Current branch master is up to date.

But 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:

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

One 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.

Now, 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.

So 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
  git config remote.REPOS_ALIAS.url hg::the_computed_absolute_path

This 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). 

So, 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?

One 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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to