{"thread":{"id":"32576","subject":"[PATCH] remote-hg: store converted URL","startedAt":"2013-01-09T19:43:38Z","lastAt":"2013-01-15T20:10:19Z","messageCount":8,"participants":["Max Horn","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"206409","messageId":"1357760618-81222-1-git-send-email-max@quendi.de","threadId":"32576","inReplyTo":null,"subject":"[PATCH] remote-hg: store converted URL","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-01-09T19:43:38Z","receivedAt":"2013-01-09T19:43:38Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"From: Felipe Contreras \n\nMercurial might convert the URL to something more appropriate, like an\nabsolute path. Lets store that instead of the original URL, which won't\nwork from a different working directory if it's relative.\n\nSuggested-by: Max Horn \nSigned-off-by: Felipe Contreras \nSigned-off-by: Max Horn \n---\nFor a discussion of the problem, see also\n http://article.gmane.org/gmane.comp.version-control.git/210250\nWhile I am not quite happy with using \"git config\" to solve it, there\ndoesn't seem to be a better way right now.\n\n contrib/remote-helpers/git-remote-hg | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex c700600..7c74d8b 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -720,6 +720,14 @@ def do_export(parser):\n if peer:\n parser.repo.push(peer, force=False)\n \n+def fix_path(alias, repo, orig_url):\n+ repo_url = util.url(repo.url())\n+ url = util.url(orig_url)\n+ if str(url) == str(repo_url):\n+ return\n+ cmd = ['git', 'config', 'remote.%s.url' % alias, \"hg::%s\" % repo_url]\n+ subprocess.call(cmd)\n+\n def main(args):\n global prefix, dirname, branches, bmarks\n global marks, blob_marks, parsed_refs\n@@ -766,6 +774,9 @@ def main(args):\n repo = get_repo(url, alias)\n prefix = 'refs/hg/%s' % alias\n \n+ if not is_tmp:\n+ fix_path(alias, peer or repo, url)\n+\n if not os.path.exists(dirname):\n os.makedirs(dirname)\n \n-- \n1.8.0.1.525.gaaf5ad5\n"},{"id":"206821","messageId":"7vmwwbd43o.fsf@alter.siamese.dyndns.org","threadId":"32576","inReplyTo":"1357760618-81222-1-git-send-email-max@quendi.de","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-14T18:14:19Z","receivedAt":"2013-01-14T18:14:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn writes:\n\n> From: Felipe Contreras \n>\n> Mercurial might convert the URL to something more appropriate, like an\n> absolute path.\n\n\"What it is converted *TO*\" is fairly clear with \", like an ...\",\nbut from the first reading it was unclear to me \"what it is\nconverted *FROM*\" and \"*WHEN* the conversion happens\". Do you mean\nthat the user gives \"git clone\" an URL \"../hg-repo\" via the command\nline (e.g. the argument to \"git clone\" is spelled something like\n\"hg::../hg-repo\"), and that \"../hg-repo\" is rewritten to something\nelse (an absolute path, e.g. \"/srv/project/hg-repo\")?\n\n> Lets store that instead of the original URL, which won't\n> work from a different working directory if it's relative.\n\nWhat is lacking from this description is why it even needs to work\nfrom a different working directory. I am guessing that remote-hg\nlater creates a hidden Hg repository or something in a different\nplace and still tries to use the URL to interact with the upstream,\nand that is what breaks, but with only the above description without\nlooking at your original report, people who will read the \"git log\"\noutput and find this change will not be able to tell why this was\nneeded, I am afraid.\n\nOf course, the above guess of mine may even be wrong, but then that\nis yet another reason that the log needs to explain the change\nbetter.\n\n> Suggested-by: Max Horn \n> Signed-off-by: Felipe Contreras \n> Signed-off-by: Max Horn \n> ---\n> For a discussion of the problem, see also\n> http://article.gmane.org/gmane.comp.version-control.git/210250\n\nI do not see any discussion; only your problem report.\n\nWas this work done outside the list? I just want to make sure this\npatch is not something Felipe did not want to sign off for whatever\nreason but you are passing it to the list as a patch signed off by\nhim.\n"},{"id":"206930","messageId":"64C81CD0-960A-47F2-89FC-8D3126B1F4D5@quendi.de","threadId":"32576","inReplyTo":"7vmwwbd43o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-01-15T11:41:44Z","receivedAt":"2013-01-15T11:41:44Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 14.01.2013, at 19:14, Junio C Hamano wrote:\n\n> Max Horn writes:\n> \n>> From: Felipe Contreras \n>> \n>> Mercurial might convert the URL to something more appropriate, like an\n>> absolute path.\n> \n> \"What it is converted *TO*\" is fairly clear with \", like an ...\",\n> but from the first reading it was unclear to me \"what it is\n> converted *FROM*\" and \"*WHEN* the conversion happens\". Do you mean\n> that the user gives \"git clone\" an URL \"../hg-repo\" via the command\n> line (e.g. the argument to \"git clone\" is spelled something like\n> \"hg::../hg-repo\"), and that \"../hg-repo\" is rewritten to something\n> else (an absolute path, e.g. \"/srv/project/hg-repo\")?\n\nYes, that was meant. \n\n> \n>> Lets store that instead of the original URL, which won't\n>> work from a different working directory if it's relative.\n> \n> What is lacking from this description is why it even needs to work\n> from a different working directory. I am guessing that remote-hg\n> later creates a hidden Hg repository or something in a different\n> place and still tries to use the URL to interact with the upstream,\n> and that is what breaks, but with only the above description without\n> looking at your original report, people who will read the \"git log\"\n> output and find this change will not be able to tell why this was\n> needed, I am afraid.\n> \n> Of course, the above guess of mine may even be wrong, but then that\n> is yet another reason that the log needs to explain the change\n> better.\n\nFully agreed. How about this commit message:\n\n-- >8 --\nremote-hg: store converted URL of hg repo in git config\n\nWhen remote-hg is invoked, read the remote repository URL from the git config,\ngive Mercurial a chance to expand it, and if changed, store it back into\nthe git config.\n\nThis fixes the following problem: Suppose you clone a local hg repository\nusing a relative path, e.g.\n git clone hg::hgrepo gitrepo\nThis stores \"hg::hgrepo\" in gitrepo/.git/config. However, no information\nabout the PWD is stored, making it impossible to correctly interpret the\nrelative path later on. Thus when latter attempting to, say, \"git pull\"\nfrom inside gitrepo, remote-hg cannot resolve the relative path correctly,\nand the user sees an unexpected error.\n\nWith this commit, the URL \"hg::hgrepo\" gets expanded (during cloning,\nbut also during any other remote operation) and the resulting absolute\nURL (e.g. \"hg::/abspath/hgrepo\") is stored in gitrepo/.git/config.\nThus the git clone of hgrepo becomes usable.\n-- >8 --\n\n> \n>> Suggested-by: Max Horn \n>> Signed-off-by: Felipe Contreras \n>> Signed-off-by: Max Horn \n>> ---\n>> For a discussion of the problem, see also\n>> http://article.gmane.org/gmane.comp.version-control.git/210250\n> \n> I do not see any discussion; only your problem report.\n\nAha, 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 duri\n ng a clone or a pull; hence it has to \"expand\" and rewrite the URL every time it is called, just in case.\n\n\nAnyway, as long as this particular command works somehow, I am fine:\n\n git clone hg::../relative/path/to/hg-repo git-repo\n\n\n> Was this work done outside the list? I just want to make sure this\n> patch is not something Felipe did not want to sign off for whatever\n> reason but you are passing it to the list as a patch signed off by\n> him.\n\nThe work was done by Felipe's and published in his github repository:\n https://github.com/felipec/git/commit/605bad5b52d2fcf3d8f5fd782a87d7c97d1b040a\nSee also the discussion (yeah, this time a real one ;-) leading to this:\n https://github.com/felipec/git/issues/2\n\nI 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.\n\nCheers,\nMax\n\n\nPS: recently, yet another tool has (re)emerged for using hg repos from inside git:\n https://github.com/buchuki/gitifyhg\nThis 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...\n"},{"id":"206944","messageId":"7vzk0a4ekj.fsf@alter.siamese.dyndns.org","threadId":"32576","inReplyTo":"64C81CD0-960A-47F2-89FC-8D3126B1F4D5@quendi.de","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T16:05:16Z","receivedAt":"2013-01-15T16:05:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn writes:\n\n> On 14.01.2013, at 19:14, Junio C Hamano wrote:\n>\n>> What is lacking from this description is why it even needs to work\n>> from a different working directory....\n\nIn your rewrite below, this is still lacking, I think.\n\n> Fully agreed. How about this commit message:\n>\n> -- >8 --\n> remote-hg: store converted URL of hg repo in git config\n>\n> When remote-hg is invoked, read the remote repository URL from the git config,\n> give Mercurial a chance to expand it, and if changed, store it back into\n> the git config.\n>\n> This fixes the following problem: Suppose you clone a local hg repository\n> using a relative path, e.g.\n> git clone hg::hgrepo gitrepo\n> This stores \"hg::hgrepo\" in gitrepo/.git/config. However, no information\n> about the PWD is stored, making it impossible to correctly interpret the\n> relative path later on.\n\nHere, you say \"correctly interpret relative path later on\", but it\nis not made clear why it is even necessary. And that makes ...\n\n> Thus when latter attempting to, say, \"git pull\"\n> from inside gitrepo, remote-hg cannot resolve the relative path correctly,\n> and the user sees an unexpected error.\n\n... \"cannot resolve the relative path correctly\" above sound like a\nbug in remote-hg. Something like:\n\n Cloning a local hg repository using a relative path, e.g.\n\n git clone hg::hgrepo gitrepo\n\n stores \"hg::hgrepo\" in gitrepo/.git/config as its URL. When\n remote-hg is invoked by \"git fetch\", it chdirs to X (which is\n different from the \"gitrepo\" directory) and uses the URL (which\n is not correct, as it is a relative path but the cwd is\n different when it is used) to interact with the original\n \"hgrepo\", which will fail.\n\nis needed, but you didn't explain what that X is. Perhaps it is a\ntemporary directory. Perhaps it is a hidden Hg repository somewhere\nin gitrepo/.git directory. Or something else.\n\nWith that explained ...\n\n> With this commit, the URL \"hg::hgrepo\" gets expanded (during cloning,\n> but also during any other remote operation) and the resulting absolute\n> URL (e.g. \"hg::/abspath/hgrepo\") is stored in gitrepo/.git/config.\n> Thus the git clone of hgrepo becomes usable.\n\n... the description of the fix start making sense, but not without.\n\n>> Was this work done outside the list? I just want to make sure this\n>> patch is not something Felipe did not want to sign off for whatever\n>> reason but you are passing it to the list as a patch signed off by\n>> him.\n>\n> The work was done by Felipe's and published in his github repository:\n> https://github.com/felipec/git/commit/605bad5b52d2fcf3d8f5fd782a87d7c97d1b040a\n> See also the discussion (yeah, this time a real one ;-) leading to this:\n> https://github.com/felipec/git/issues/2\n>\n> I took his sign-off from there and interpreted it as saying that\n> Felipe was OK with this being pushed to git.git. But perhaps this\n> is not what I should have done?\n\nYou did nothing wrong, other than not having given the necessary\ncontext to understand how the change flowed here and it is kosher.\n\nWhich you now have, so it is OK.\n\nThanks.\n"},{"id":"206948","messageId":"7vr4lm4cez.fsf@alter.siamese.dyndns.org","threadId":"32576","inReplyTo":"7vzk0a4ekj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T16:51:48Z","receivedAt":"2013-01-15T16:51:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Max Horn writes:\n> ...\n>> See also the discussion (yeah, this time a real one ;-) leading to this:\n>> https://github.com/felipec/git/issues/2\n>> ...\n\nIf I understand correctly, the $backend::$opaqueToken is a contract\nbetween the remote-helper and the remote-$backend that says \"When\nuser wants to interact with the same (foreign) repository, we agreed\nto let her use 'origin' nickname. The remote-helper looks up this\nopaque token that corresponds to 'origin' and gives it to the\nremote-$backend, and whatever is in the opaque token should be\nsufficient for the remote-$backend to figure out how to proceed from\nthere\".\n\nBut in this hg::../over/there case, it seems that string is not\nsufficient for remote-hg to do so and the contract is broken.\n\nWhen \"git clone $backend::$opaqueToken repo\" is run in /dir/ecto/ry,\nand then subsequent \"git fetch origin\" will be run in (a\nsubdirectory of) /dir/ecto/ry/repo, but anything relative to\n/dir/ecto/ry will not work once you go inside /dir/ecto/ry/repo.\nThe \"create a new repository here\" argument could even be an\nabsolute path to a totally different place, so if the\nremote-$backend wants to use $opaqueToken as anything relative to\nthe $(cwd) when \"git clone\" was invoked, that original location\nneeds to be available somehow.\n\nWould a new helper protocol message be necessary, so that the\nbackend can rewrite the $opaqueToken at \"clone\" time and tell the\nhelper what to store as URL instead of the original? I do not think\nthat is much different from remote-$backend updating the value of the\nremote.origin.URL using \"git config\".\n\nAn alternative approach may be for somebody (either the \"git clone\"\nor the remote-$backend) to store a \"base directory\" when \"git clone\"\nwas invoked in remote.origin.dirAtCloneTime variable, so that the\nnext time remote-$backend runs, it can read that directory and\ninterpret the $opaqueToken as a relative path to that directory if\nit wants to. That way, nobody needs to rewrite $opaqueToken.\n\nHow do other remote helpers solve this, I have to wonder, though.\nBy not allowing relative paths to a directory?\n"},{"id":"206955","messageId":"1C0B25E7-40B2-46AC-B730-1EBDC8A82B7C@quendi.de","threadId":"32576","inReplyTo":"7vzk0a4ekj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-01-15T17:46:22Z","receivedAt":"2013-01-15T17:46:22Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 15.01.2013, at 17:05, Junio C Hamano wrote:\n\n> Max Horn writes:\n> \n>> On 14.01.2013, at 19:14, Junio C Hamano wrote:\n>> \n>>> What is lacking from this description is why it even needs to work\n>>> from a different working directory....\n> \n> In your rewrite below, this is still lacking, I think.\n\nHm, I thought I made it clear: It has to change because relative paths only make sense when you know the reference point they are relative with.\n\nTypically. This is the pwd. But when I \n\n git clone repo newrepo\n cd newrepo\n\nI just changed the PWD. The clone command was given the relative path \"repo\". If git were to use that, it would suddenly refer to a directory inside newrepo, not next to it. Bang. Hence, git expands the relative path to an absolute one in the above example.\n\nBut git cannot do that for URLs in the form HELPER::PATH, because such a string is necessarily opaque to git.\n\n\n\n>> Thus when latter attempting to, say, \"git pull\"\n>> from inside gitrepo, remote-hg cannot resolve the relative path correctly,\n>> and the user sees an unexpected error.\n> \n> ... \"cannot resolve the relative path correctly\" above sound like a\n> bug in remote-hg. Something like:\n> \n> Cloning a local hg repository using a relative path, e.g.\n> \n> git clone hg::hgrepo gitrepo\n> \n> stores \"hg::hgrepo\" in gitrepo/.git/config as its URL. When\n> remote-hg is invoked by \"git fetch\", it chdirs to X (which is\n> different from the \"gitrepo\" directory) and uses the URL (which\n> is not correct, as it is a relative path but the cwd is\n> different when it is used) to interact with the original\n> \"hgrepo\", which will fail.\n> \n> is needed, but you didn't explain what that X is. Perhaps it is a\n> temporary directory. Perhaps it is a hidden Hg repository somewhere\n> in gitrepo/.git directory. Or something else.\n\nNone of the above. Nor does the remote helper chdir anywhere. It is the user who has done the chdir: Away from the location he invoked \"git clone\" at, and into the new repository directory that previously did not even exist.\n\n\n\nCheers,\nMax"},{"id":"206956","messageId":"B35B3EA6-F01B-46D8-AC3D-0F7C8A45A06B@quendi.de","threadId":"32576","inReplyTo":"7vr4lm4cez.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-01-15T18:10:01Z","receivedAt":"2013-01-15T18:10:01Z","isPatch":true,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 15.01.2013, at 17:51, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n>> Max Horn writes:\n>> ...\n>>> See also the discussion (yeah, this time a real one ;-) leading to this:\n>>> https://github.com/felipec/git/issues/2\n>>> ...\n> \n> If I understand correctly, the $backend::$opaqueToken is a contract\n> between the remote-helper and the remote-$backend\n\nJust to clarify: What is the \"remote-helper\" ? So far, I thought of this being a contract between git (or some part of git), and remote-$backend (i.e. remote-hg in this case). \n\n\n> that says \"When\n> user wants to interact with the same (foreign) repository, we agreed\n> to let her use 'origin' nickname. The remote-helper looks up this\n> opaque token that corresponds to 'origin' and gives it to the\n> remote-$backend, and whatever is in the opaque token should be\n> sufficient for the remote-$backend to figure out how to proceed from\n> there\".\n\nSupposing that I interpret \"remote-helper\" correctly, that sounds about right to me.\n\n> \n> But in this hg::../over/there case, it seems that string is not\n> sufficient for remote-hg to do so and the contract is broken.\n\nOne could put it that way.\n\n> \n> When \"git clone $backend::$opaqueToken repo\" is run in /dir/ecto/ry,\n> and then subsequent \"git fetch origin\" will be run in (a\n> subdirectory of) /dir/ecto/ry/repo, but anything relative to\n> /dir/ecto/ry will not work once you go inside /dir/ecto/ry/repo.\n> The \"create a new repository here\" argument could even be an\n> absolute path to a totally different place, so if the\n> remote-$backend wants to use $opaqueToken as anything relative to\n> the $(cwd) when \"git clone\" was invoked, that original location\n> needs to be available somehow.\n\nThat would be one option. Another is to do what the proposed patch does, and what git itself does: Change the relative path into an absolute one. This requires remote-$backend to be able to modify the opaque token supplied by the user.\n\nYet another would be to be more strict in remote-$backend as to which opaque tokens to accept: When it contains a relative path, simply always refuse to work, even if the PWD happens to be set the right way. Of course this would be quite undesirable from a user's perspective.\n\n\n> \n> Would a new helper protocol message be necessary, so that the\n> backend can rewrite the $opaqueToken at \"clone\" time and tell the\n> helper what to store as URL instead of the original? I do not think\n> that is much different from remote-$backend updating the value of the\n> remote.origin.URL using \"git config\".\n> \n> An alternative approach may be for somebody (either the \"git clone\"\n> or the remote-$backend) to store a \"base directory\" when \"git clone\"\n> was invoked in remote.origin.dirAtCloneTime variable, so that the\n> next time remote-$backend runs, it can read that directory and\n> interpret the $opaqueToken as a relative path to that directory if\n> it wants to. That way, nobody needs to rewrite $opaqueToken.\n\nAs I said above, this would be an option. However, I would prefer rewriting the $opaqueToken, as that would be closer to what git does for \"native\" tokens passed to \"git clone\" Specifically, I am talking about get_repo_path() in builtin/clone.c which is called by cmd_clone. What this does is in my eyes essentially the equivalent of what the patch discussed here is doing.\n\nAnyway, at the end of the day, I mainly care about relative paths working, somehow :-). But I think it would be important to make the issue easy to resolve for all remote-$backend authors, as many of them are affected (see below).\n\n> \n> How do other remote helpers solve this, I have to wonder, though.\n> By not allowing relative paths to a directory?\n\nSo far, all I look at do not deal with this at all. Any attempts to deal with it should be pretty easy to recognize: The remote-$backend would have to store something into the git config, or else, verify the opaque token and refuse to work with it under certain conditions (e.g. when it contains a relative path). But they don't. E.g. git-remote-testgit has the exact same problem. Doing\n\n git init repo && cd repo && echo a > a && git add a && git ci -m a a\n git clone testgit::repo clone\n cd clone\n\nresults in a .git/config file containing\n\n[remote \"origin\"]\n\turl = testgit::repo\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n\nTrying to do a \"git push\" from within the clone then gives this:\n\nfatal: 'repo/.git' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\nTraceback (most recent call last):\n File \"/usr/local/libexec/git-core/git-remote-testgit\", line 272, in \n sys.exit(main(sys.argv))\n File \"/usr/local/libexec/git-core/git-remote-testgit\", line 261, in main\n repo = get_repo(alias, url)\n File \"/usr/local/libexec/git-core/git-remote-testgit\", line 39, in get_repo\n repo.get_revs()\n File \"/usr/local/lib/python2.7/site-packages/git_remote_helpers/git/repo.py\", line 59, in get_revs\n check_call(args, stdout=ofile)\n File \"/usr/local/lib/python2.7/site-packages/git_remote_helpers/util.py\", line 174, in check_call\n raise CalledProcessError(retcode, cmd)\nsubprocess.CalledProcessError: Command '['git', 'ls-remote', 'repo/.git']' returned non-zero exit status 128\n\n\n\n\nCheers,\nMax"},{"id":"206969","messageId":"7vobgq2ono.fsf@alter.siamese.dyndns.org","threadId":"32576","inReplyTo":"B35B3EA6-F01B-46D8-AC3D-0F7C8A45A06B@quendi.de","subject":"Re: [PATCH] remote-hg: store converted URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T20:10:19Z","receivedAt":"2013-01-15T20:10:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Max Horn writes:\n\n> So far, all I look at do not deal with this at all. Any attempts\n> to deal with it should be pretty easy to recognize: The\n> remote-$backend would have to store something into the git config,\n> or else, verify the opaque token and refuse to work with it under\n> certain conditions (e.g. when it contains a relative path). But\n> they don't. E.g. git-remote-testgit has the exact same problem.\n\nThanks for confirming what I suspected. I think the way Felipe's\npatch makes remote-hg take responsibility of how $opaqueToken should\nlook like for future invocations is the simplest and makes the most\nsense. We could try to go fancier and end up over-engineering, but\nI'd rather have a simple fix in the tree first.\n\nThanks.\n"}]}