On 14.01.2013, at 19:14, Junio C Hamano wrote: > Max Horn <max@xxxxxxxxx> writes: > >> From: Felipe Contreras <felipe.contreras@xxxxxxxxx> >> >> 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 > better. 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 <max@xxxxxxxxx> >> Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> >> Signed-off-by: Max Horn <max@xxxxxxxxx> >> --- >> For a discussion of the problem, see also >> http://article.gmane.org/gmane.comp.version-control.git/210250 > > 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 > him. The work was done by Felipe's and published in his github repository: https://github.com/felipec/git/commit/605bad5b52d2fcf3d8f5fd782a87d7c97d1b040a See also the discussion (yeah, this time a real one ;-) leading to this: https://github.com/felipec/git/issues/2 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. Cheers, Max PS: recently, yet another tool has (re)emerged for using hg repos from inside git: https://github.com/buchuki/gitifyhg 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 ones... -- 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