On Windows, after cloning with a ssh address given by Gitlab or Github (for this example git@gricad-gitlab.univ-grenoble-alpes.fr:meige-legi/scientific-computing-m2-efm.git), the path is wrong:
Instead, the correct path to push is
git+ssh://git@gricad-gitlab.univ-grenoble-alpes.fr:meige-legi/scientific-computing-m2-efm.git
If one uses this address, the default path is fine, but this is not the address given by Gitlab or Github, which do not include the git+ssh://.
It seems that hg-git thinks the given path is a relative path and it tries to transform it to an absolute path. Do you know where it is done? I can try to work on a fix (since I have access to a Windows computer where I can reproduce).
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
It seems that hg-git thinks the given path is a relative path and it tries to transform it to an absolute path. Do you know where it is done?
I'd say the two most likely culprits are get_transport_and_path() in git_handler.py and isgitsshuri() in util.py. One thing to keep an eye out for is whether Mercurial itself does some processing of the path behinds the scenes; it might detect that xxx:whatever is a Windows path and transform it somehow. That's just a guess, though.
(One possible workaround is to use git+ssh://git@gricad-gitlab.univ-grenoble-alpes.fr/meige-legi/scientific-computing-m2-efm.git — I believe that also works with recent versions of Git.)
I finally managed to work on this with a computer on Windows. Unfortunately, I didn't find the problem.
get_transport_and_path() and isgitsshuri() seem to work fine (which is consistent with the fact that there is no error and that the repository is correctly cloned).
I don't know/understand enough Mercurial internal to locate the problem with the wrong default path.
It would be great if anyone can tell me where to look to better understand this bug? CC @marmoute@gracinet?
Perhaps we should fix this by converting clone URLs to the git+ssh://example.com/repo.git style?
Apparently, that requires patching Mercurial. However, a more restricted change ought to fix that — would it be possible for you to apply it to Mercurial and test?
# HG changeset patch# User Dan Villiom Podlaski Christiansen <danchr@gmail.com># Date 1608055342 -3600# Tue Dec 15 19:02:22 2020 +0100# Node ID b5aac377ad16fe56f982f23a1b87ac4ca254bbfb# Parent c581b9ee22b18b2b0c560a2ec9ebfcae9790af59clone: let the peer determine whether a source is localGit has a rather loose approach to how users may specify repositories,allowing both regular URIs, scp-style paths and combinations thereof.An hg-git user reported that this caused an invalid path in `.hg/hgrc`on Windows.[1]I suspect the root cause is that islocal() is too aggressive, andreturns True for some Git locations. Tightening the check to ensurethat we also have a local repository ought to fix this.[1] <https://foss.heptapod.net/mercurial/hg-git/-/issues/335>diff --git a/mercurial/hg.py b/mercurial/hg.py--- a/mercurial/hg.py+++ b/mercurial/hg.py@@ -810,7 +810,7 @@ def clone( srcrepo = srcpeer.local() try: abspath = origsource- if islocal(origsource):+ if islocal(origsource) and srcrepo: abspath = os.path.abspath(util.urllocalpath(origsource)) if islocal(dest):
I confirm that the patch improves the situation. The default path is correct. However, hg pull still does not work:
> cat .\.hg\hgrc# example repository config (see 'hg help config' for more info)[paths]default = git@gricad-gitlab.univ-grenoble-alpes.fr:meige-legi/scientific-computing-m2-efm.git> hg pullssh: Could not resolve hostname c: H\364te inconnu.pulling from C:\Users\paugier\tmp\scientific-computing-m2-efm\git@gricad-gitlab.univ-grenoble-alpes.fr:meige-legi\scientific-computing-m2-efm.gitabort: git remote error: The remote server unexpectedly closed the connection.