On 14.01.2013, at 19:14, Junio C Hamano wrote:
> Max Horn <m...@quendi.de> writes:
>> From: Felipe Contreras <felipe.contre...@gmail.com>
>> Mercurial might convert the URL to something more appropriate, like an
>> absolute path.
> "What it is converted *TO*" is fairly clear with ", like an ...",
> but from the first reading it was unclear to me "what it is
> converted *FROM*" and "*WHEN* the conversion happens". Do you mean
> that the user gives "git clone" an URL "../hg-repo" via the command
> line (e.g. the argument to "git clone" is spelled something like
> "hg::../hg-repo"), and that "../hg-repo" is rewritten to something
> else (an absolute path, e.g. "/srv/project/hg-repo")?
Yes, that was meant.
>> Lets store that instead of the original URL, which won't
>> work from a different working directory if it's relative.
> What is lacking from this description is why it even needs to work
> from a different working directory. I am guessing that remote-hg
> later creates a hidden Hg repository or something in a different
> place and still tries to use the URL to interact with the upstream,
> and that is what breaks, but with only the above description without
> looking at your original report, people who will read the "git log"
> output and find this change will not be able to tell why this was
> needed, I am afraid.
> Of course, the above guess of mine may even be wrong, but then that
> is yet another reason that the log needs to explain the change
Fully agreed. How about this commit message:
-- >8 --
remote-hg: store converted URL of hg repo in git config
When remote-hg is invoked, read the remote repository URL from the git config,
give Mercurial a chance to expand it, and if changed, store it back into
the git config.
This fixes the following problem: Suppose you clone a local hg repository
using a relative path, e.g.
git clone hg::hgrepo gitrepo
This stores "hg::hgrepo" in gitrepo/.git/config. However, no information
about the PWD is stored, making it impossible to correctly interpret the
relative path later on. Thus when latter attempting to, say, "git pull"
from inside gitrepo, remote-hg cannot resolve the relative path correctly,
and the user sees an unexpected error.
With this commit, the URL "hg::hgrepo" gets expanded (during cloning,
but also during any other remote operation) and the resulting absolute
URL (e.g. "hg::/abspath/hgrepo") is stored in gitrepo/.git/config.
Thus the git clone of hgrepo becomes usable.
-- >8 --
>> Suggested-by: Max Horn <m...@quendi.de>
>> Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
>> Signed-off-by: Max Horn <m...@quendi.de>
>> For a discussion of the problem, see also
> I do not see any discussion; only your problem report.
Aha, an english language issue on my side I guess: For me, a single person can
"discuss" a problem (often, a research paper is said to be "discussing a
problem"). Sorry for that. Anyway, the reason I gave that link was because it
attempts explains the problem and one solution (which this patch ended up
implementing), but also express that I feel a bit uncomfortable with this.
Which I still do. Relying on the remote helper to invoke "git config" feels
like a hack and I was wondering whether this is deemed an acceptable solution
-- or whether one should instead extend the remote-helper protocol, allowing
the remote helper to signal a rewritten remote URL (perhaps only directly after
a clone?). As it is, the remote helper seems (?) to have no way to distinguish
whether it is being called during a clone or a pull; hence it has to "expand"
and rewrite the URL every time it is called, just in case.
Anyway, as long as this particular command works somehow, I am fine:
git clone hg::../relative/path/to/hg-repo git-repo
> Was this work done outside the list? I just want to make sure this
> patch is not something Felipe did not want to sign off for whatever
> reason but you are passing it to the list as a patch signed off by
The work was done by Felipe's and published in his github repository:
See also the discussion (yeah, this time a real one ;-) leading to this:
I took his sign-off from there and interpreted it as saying that Felipe was OK
with this being pushed to git.git. But perhaps this is not what I should have
done? In that case I am very sorry :-(. It's just that I feel this patch is
quite useful and important for daily use (which is why I suggested it in the
first place ;-), so I was/am quite eager to see it in.
PS: recently, yet another tool has (re)emerged for using hg repos from inside
This is partially based on Felipe's work, but has several bug fixes atop that.
It is also seems to be a priority for its author, so it os more actively
developed... anyway, that's now, what, "solution" #5 or #6? I really hope the
dust on this will settle soon and we'll have just one (or maybe two) tools
doing a decent job, instead of attention splitting over so many different
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