{"thread":{"id":"46621","subject":"Revision resolution for remote-helpers?","startedAt":"2017-08-18T06:56:18Z","lastAt":"2017-09-21T01:13:21Z","messageCount":11,"participants":["Mike Hommey","Jeff King","Jonathan Nieder","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"326678","messageId":"20170818064208.plkppke7efpucuwm@glandium.org","threadId":"46621","inReplyTo":null,"subject":"Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-08-18T06:42:08Z","receivedAt":"2017-08-18T06:56:18Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nAs you might remember, I'm maintaining a remote helper that allows to\ntalk directly to mercurial servers with git: git-cinnabar.\n\nWhen dealing with \"foreign (non-git) repositories\", it is often\nnecessary to refer to revisions with their native name. With mercurial,\nthat's a sha1, with svn it's a revision number, etc.\n\nGit-cinnabar does provide a helper command that gives back the git\ncommit from the mercurial revision (and vice versa), but that's\ncumbersome to use in commands.\n\nI was thinking it could be useful to have a special syntax for revisions\nthat would query a helper program. The helper program could use a\nsimilar protocol to that of the remote helpers.\n\nMy thought is that a string like :: could be used\nwherever a committish is expected. That would call some helper\nand request to resolve revision, and the helper would provide a git\ncommit as a response.\n\nThe reason for the :: prefix is that it matches the ::\nprefix used for remote helpers.\n\nNow, there are a few caveats:\n- , for e.g. svn, pretty much would depend on the remote.\n OTOH, in mercurial, it doesn't. I think it would be fair for the\n helper to have to deal with making what appears after :: relevant\n to find the right revision, by possibly including a remote name.\n- msys likes to completely fuck up command lines when they contain ::.\n For remote helpers, the alternative that works is\n :///etc.\n\nWhich leads me to think some \"virtual\" ref namespace could be a solution\nto the problem. So instead of ::, the prefix would be /.\nFor e.g. svn, svn/$remote/$rev would be a natural way to specify the\nrevision for a given remote. For mercurial, hg/$sha1.\n\nPotentially, this could be a sort of pluggable ref stores, which could\nbe used for extensions such as the currently discussed reftable.\n\nOn the opposite end of the problem, I'm also thinking about git log\n--decorate= displaying the mercurial revisions where branch\ndecorations would normally go.\n\nI have no patch to show for it. Those are ideas that I first want to\ndiscuss before implementing anything.\n\nThoughts?\n\nMike\n"},{"id":"326688","messageId":"20170818121509.fjsmzkdaokyjuaya@sigill.intra.peff.net","threadId":"46621","inReplyTo":"20170818064208.plkppke7efpucuwm@glandium.org","subject":"Re: Revision resolution for remote-helpers?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-18T12:15:09Z","receivedAt":"2017-08-18T12:15:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:\n\n> I was thinking it could be useful to have a special syntax for revisions\n> that would query a helper program. The helper program could use a\n> similar protocol to that of the remote helpers.\n\nThat sounds like a reasonable thing to want.\n\n> My thought is that a string like :: could be used\n> wherever a committish is expected. That would call some helper\n> and request to resolve revision, and the helper would provide a git\n> commit as a response.\n\nSo I'm guessing this would look something like:\n\n git log svn::12345\n\nI think even without Git support, you could do something like:\n\n git log $(git svn map 12345)\n\nwhich is similarly complex in terms of concepts, and not too many more\ncharacters. That would be a little more awkward outside of a shell,\nthough.\n\nBut it did get me wondering if we could do _better_ with something built\ninto Git. For example, could we have an external resolution helper that\nresolves names to object ids as a fallback after internal resolution has\nfailed. And then you could do:\n\n git log 12345\n\nand it would just work. Efficiency shouldn't be a big problem, because\nwe'd hit the helper only in the error case.\n\nI'd be more concerned about awkward ambiguities, though. If mercurial is\nalso using sha1s, then there's nothing syntactic to differentiate the\ntwo. For that matter, 12345 has the same problem, since it could be a\npartial sha1.\n\nIt might work to actually check if we have the object and then bail\nto the remote resolver only if we don't. But that's actually conflating\nname resolution with object lookup, which our internals typically keep\nseparate.\n\nSo maybe this is a bad direction to go in. I'm mostly just thinking out\nloud here.\n\n> Which leads me to think some \"virtual\" ref namespace could be a solution\n> to the problem. So instead of ::, the prefix would be /.\n> For e.g. svn, svn/$remote/$rev would be a natural way to specify the\n> revision for a given remote. For mercurial, hg/$sha1.\n\nInteresting. I do like the general idea of having external helpers to\nfill in bits of the virtual namespace. But it may also open many cans of\nworms. :)\n\n> Potentially, this could be a sort of pluggable ref stores, which could\n> be used for extensions such as the currently discussed reftable.\n\nThe current pluggable code is definitely geared for build-time\npluggability, not runtime. But I think you could have a builtin\npluggable store that does the overlay, and then chains to another\nbackend. I.e., configure something like:\n\n [extensions]\n refBackend = externalOverlay\n\n [externalOverlay \"svn\"]\n namespace = refs/svn\n command = my-svn-mapper\n\n [externalOverlay]\n chain = reftable\n\nThat would allow the externalOverlay thing to develop independent of the\ncore of Git's refs code.\n\n> On the opposite end of the problem, I'm also thinking about git log\n> --decorate= displaying the mercurial revisions where branch\n> decorations would normally go.\n\nInteresting thought. I'm not sure if that would be a good thing or a bad\nthing. But one of the virtual methods for pluggable backends is\n\"enumerate all refs\". If you're mapping every mercurial revision, that's\ngoing to be a lot of refs (and potentially a lot of overhead for certain\noperations).\n\nI think the decorate code just looks at a few parts of the refs\nnamespace right now (so a \"refs/svn\" would probably get ignored by\ndefault).\n\n-Peff\n"},{"id":"326721","messageId":"20170818215702.6pjrcsl7yxepqhyp@glandium.org","threadId":"46621","inReplyTo":"20170818121509.fjsmzkdaokyjuaya@sigill.intra.peff.net","subject":"Re: Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-08-18T21:57:02Z","receivedAt":"2017-08-18T21:57:12Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote:\n> On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:\n> \n> > I was thinking it could be useful to have a special syntax for revisions\n> > that would query a helper program. The helper program could use a\n> > similar protocol to that of the remote helpers.\n> \n> That sounds like a reasonable thing to want.\n> \n> > My thought is that a string like :: could be used\n> > wherever a committish is expected. That would call some helper\n> > and request to resolve revision, and the helper would provide a git\n> > commit as a response.\n> \n> So I'm guessing this would look something like:\n> \n> git log svn::12345\n> \n> I think even without Git support, you could do something like:\n> \n> git log $(git svn map 12345)\n\nThat's what I do, but subshells and all is extra cumbersome.\n\n> which is similarly complex in terms of concepts, and not too many more\n> characters. That would be a little more awkward outside of a shell,\n> though.\n> \n> But it did get me wondering if we could do _better_ with something built\n> into Git. For example, could we have an external resolution helper that\n> resolves names to object ids as a fallback after internal resolution has\n> failed. And then you could do:\n> \n> git log 12345\n> \n> and it would just work. Efficiency shouldn't be a big problem, because\n> we'd hit the helper only in the error case.\n> \n> I'd be more concerned about awkward ambiguities, though. If mercurial is\n> also using sha1s, then there's nothing syntactic to differentiate the\n> two. For that matter, 12345 has the same problem, since it could be a\n> partial sha1.\n\nFor something as short, the likelihood of hitting an actual existing\nabbreviated sha1 is quite high, too.\n\n> It might work to actually check if we have the object and then bail\n> to the remote resolver only if we don't. But that's actually conflating\n> name resolution with object lookup, which our internals typically keep\n> separate.\n> \n> So maybe this is a bad direction to go in. I'm mostly just thinking out\n> loud here.\n> \n> > Which leads me to think some \"virtual\" ref namespace could be a solution\n> > to the problem. So instead of ::, the prefix would be /.\n> > For e.g. svn, svn/$remote/$rev would be a natural way to specify the\n> > revision for a given remote. For mercurial, hg/$sha1.\n> \n> Interesting. I do like the general idea of having external helpers to\n> fill in bits of the virtual namespace. But it may also open many cans of\n> worms. :)\n> \n> > Potentially, this could be a sort of pluggable ref stores, which could\n> > be used for extensions such as the currently discussed reftable.\n> \n> The current pluggable code is definitely geared for build-time\n> pluggability, not runtime. But I think you could have a builtin\n> pluggable store that does the overlay, and then chains to another\n> backend. I.e., configure something like:\n> \n> [extensions]\n> refBackend = externalOverlay\n> \n> [externalOverlay \"svn\"]\n> namespace = refs/svn\n> command = my-svn-mapper\n> \n> [externalOverlay]\n> chain = reftable\n> \n> That would allow the externalOverlay thing to develop independent of the\n> core of Git's refs code.\n\nThat's a lot of configuration, but it's definitely an interesting\nproposition.\n\n> > On the opposite end of the problem, I'm also thinking about git log\n> > --decorate= displaying the mercurial revisions where branch\n> > decorations would normally go.\n> \n> Interesting thought. I'm not sure if that would be a good thing or a bad\n> thing. But one of the virtual methods for pluggable backends is\n> \"enumerate all refs\". If you're mapping every mercurial revision, that's\n> going to be a lot of refs (and potentially a lot of overhead for certain\n> operations).\n> \n> I think the decorate code just looks at a few parts of the refs\n> namespace right now (so a \"refs/svn\" would probably get ignored by\n> default).\n\nI think decorate would need its own special entry to the \"ref query\" API\nto answer the question \"what ref points to \" instead of scanning\nthe whole namespace.\n\nMike\n"},{"id":"326724","messageId":"20170818220637.GN13924@aiede.mtv.corp.google.com","threadId":"46621","inReplyTo":"20170818064208.plkppke7efpucuwm@glandium.org","subject":"Re: Revision resolution for remote-helpers?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-08-18T22:06:37Z","receivedAt":"2017-08-18T22:06:44Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMike Hommey wrote:\n\n> My thought is that a string like :: could be used\n> wherever a committish is expected. That would call some helper\n> and request to resolve revision, and the helper would provide a git\n> commit as a response.\n\nI like this idea.\n\n> The reason for the :: prefix is that it matches the ::\n> prefix used for remote helpers.\n>\n> Now, there are a few caveats:\n> - , for e.g. svn, pretty much would depend on the remote.\n> OTOH, in mercurial, it doesn't. I think it would be fair for the\n> helper to have to deal with making what appears after :: relevant\n> to find the right revision, by possibly including a remote name.\n> - msys likes to completely fuck up command lines when they contain ::.\n> For remote helpers, the alternative that works is\n> :///etc.\n\nHm --- is there a bug already open about this (e.g. in the Git for\nWindows project or in msys) where I can read more?\n\n> Which leads me to think some \"virtual\" ref namespace could be a solution\n> to the problem. So instead of ::, the prefix would be /.\n> For e.g. svn, svn/$remote/$rev would be a natural way to specify the\n> revision for a given remote. For mercurial, hg/$sha1.\n\nI see. My naive assumption would be that a string like r12345 would be\nthe most natural way for a user to want to specify a Subversion\nrevision, but you're right that those only have meaning scoped to a\nparticular server. That makes the svn/ prefix more tolerable.\n\n> Potentially, this could be a sort of pluggable ref stores, which could\n> be used for extensions such as the currently discussed reftable.\n>\n> On the opposite end of the problem, I'm also thinking about git log\n> --decorate= displaying the mercurial revisions where branch\n> decorations would normally go.\n>\n> I have no patch to show for it. Those are ideas that I first want to\n> discuss before implementing anything.\n\nOne additional thought: unlike refs, these are not necessarily\nenumerable (and I wouldn't expect \"git show-ref\" to show them) and\nthey do not affect \"git prune\"'s reachability computation.\n\nSo internally I don't think refs is the right concept to map these to.\nI think the right layer is revision syntax handling (revision.c).\n\nThanks,\nJonathan\n"},{"id":"326725","messageId":"20170818221754.3rbh35aewj5xnu4z@glandium.org","threadId":"46621","inReplyTo":"20170818220637.GN13924@aiede.mtv.corp.google.com","subject":"Re: Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-08-18T22:17:54Z","receivedAt":"2017-08-18T22:18:03Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n> Hi,\n> \n> Mike Hommey wrote:\n> \n> > My thought is that a string like :: could be used\n> > wherever a committish is expected. That would call some helper\n> > and request to resolve revision, and the helper would provide a git\n> > commit as a response.\n> \n> I like this idea.\n> \n> > The reason for the :: prefix is that it matches the ::\n> > prefix used for remote helpers.\n> >\n> > Now, there are a few caveats:\n> > - , for e.g. svn, pretty much would depend on the remote.\n> > OTOH, in mercurial, it doesn't. I think it would be fair for the\n> > helper to have to deal with making what appears after :: relevant\n> > to find the right revision, by possibly including a remote name.\n> > - msys likes to completely fuck up command lines when they contain ::.\n> > For remote helpers, the alternative that works is\n> > :///etc.\n> \n> Hm --- is there a bug already open about this (e.g. in the Git for\n> Windows project or in msys) where I can read more?\n\nIt's entirely an msys problem. Msys has weird rules to translate between\nunix paths and windows paths on the command line, and botches everything\nas a consequence. That's by \"design\".\n\nhttp://www.mingw.org/wiki/Posix_path_conversion\n\n(Particularly, see the last two entries)\n\nThat only happens when calling native Windows programs from a msys\nshell.\n\n> > Which leads me to think some \"virtual\" ref namespace could be a solution\n> > to the problem. So instead of ::, the prefix would be /.\n> > For e.g. svn, svn/$remote/$rev would be a natural way to specify the\n> > revision for a given remote. For mercurial, hg/$sha1.\n> \n> I see. My naive assumption would be that a string like r12345 would be\n> the most natural way for a user to want to specify a Subversion\n> revision, but you're right that those only have meaning scoped to a\n> particular server. That makes the svn/ prefix more tolerable.\n> \n> > Potentially, this could be a sort of pluggable ref stores, which could\n> > be used for extensions such as the currently discussed reftable.\n> >\n> > On the opposite end of the problem, I'm also thinking about git log\n> > --decorate= displaying the mercurial revisions where branch\n> > decorations would normally go.\n> >\n> > I have no patch to show for it. Those are ideas that I first want to\n> > discuss before implementing anything.\n> \n> One additional thought: unlike refs, these are not necessarily\n> enumerable (and I wouldn't expect \"git show-ref\" to show them) and\n> they do not affect \"git prune\"'s reachability computation.\n> \n> So internally I don't think refs is the right concept to map these to.\n> I think the right layer is revision syntax handling (revision.c).\n\nMakes sense.\n\nMike\n"},{"id":"326750","messageId":"20170818223323.GO13924@aiede.mtv.corp.google.com","threadId":"46621","inReplyTo":"20170818221754.3rbh35aewj5xnu4z@glandium.org","subject":"Re: Revision resolution for remote-helpers?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-08-18T22:33:23Z","receivedAt":"2017-08-18T22:33:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote[1]:\n> On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n>> Mike Hommey wrote:\n\n>>> The reason for the :: prefix is that it matches the ::\n>>> prefix used for remote helpers.\n>>>\n>>> Now, there are a few caveats:\n[...]\n>>> - msys likes to completely fuck up command lines when they contain ::.\n>>> For remote helpers, the alternative that works is\n>>> :///etc.\n>>\n>> Hm --- is there a bug already open about this (e.g. in the Git for\n>> Windows project or in msys) where I can read more?\n>\n> It's entirely an msys problem. Msys has weird rules to translate between\n> unix paths and windows paths on the command line, and botches everything\n> as a consequence. That's by \"design\".\n>\n> http://www.mingw.org/wiki/Posix_path_conversion\n>\n> (Particularly, see the last two entries)\n>\n> That only happens when calling native Windows programs from a msys\n> shell.\n\nCc-ing the Git for Windows mailing list as an FYI.\n\nI have faint memories that some developers on that project have had to\ndelve deep into Msys path modification rules. It's possible they can\ngive us advice (e.g. about :: having been a bad choice of\nsyntax in the first place :)).\n\nThanks,\nJonathan\n\n[1] https://public-inbox.org/git/20170818221754.3rbh35aewj5xnu4z@glandium.org/\n"},{"id":"326970","messageId":"alpine.DEB.2.21.1.1708222212320.19382@virtualbox","threadId":"46621","inReplyTo":"20170818223323.GO13924@aiede.mtv.corp.google.com","subject":"Re: [git-for-windows] Re: Revision resolution for remote-helpers?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-22T20:15:20Z","receivedAt":"2017-08-22T20:15:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 18 Aug 2017, Jonathan Nieder wrote:\n\n> Mike Hommey wrote[1]:\n> > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n> >> Mike Hommey wrote:\n> \n> >>> The reason for the :: prefix is that it matches the ::\n> >>> prefix used for remote helpers.\n> >>>\n> >>> Now, there are a few caveats:\n> [...]\n> >>> - msys likes to completely fuck up command lines when they contain ::.\n> >>> For remote helpers, the alternative that works is\n> >>> :///etc.\n> >>\n> >> Hm --- is there a bug already open about this (e.g. in the Git for\n> >> Windows project or in msys) where I can read more?\n> >\n> > It's entirely an msys problem. Msys has weird rules to translate between\n> > unix paths and windows paths on the command line, and botches everything\n> > as a consequence. That's by \"design\".\n> >\n> > http://www.mingw.org/wiki/Posix_path_conversion\n> >\n> > (Particularly, see the last two entries)\n> >\n> > That only happens when calling native Windows programs from a msys\n> > shell.\n> \n> Cc-ing the Git for Windows mailing list as an FYI.\n> \n> I have faint memories that some developers on that project have had to\n> delve deep into Msys path modification rules. It's possible they can\n> give us advice (e.g. about :: having been a bad choice of\n> syntax in the first place :)).\n\nI think it is safe to assume that :: is not part of any Unix-y path. That\nis why the MSYS2 runtime does not try to play games with it by converting\nit to a Windows path.\n\n(And indeed, I just tested this, an argument of the form\n\"a::file://b/x/y/z\" is not converted to a \"Windows path\")\n\nCiao,\nDscho\n"},{"id":"327115","messageId":"20170824082350.6ed6jqkn6aeylvnv@glandium.org","threadId":"46621","inReplyTo":"alpine.DEB.2.21.1.1708222212320.19382@virtualbox","subject":"Re: [git-for-windows] Re: Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-08-24T08:23:50Z","receivedAt":"2017-08-24T08:24:44Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 18 Aug 2017, Jonathan Nieder wrote:\n> \n> > Mike Hommey wrote[1]:\n> > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n> > >> Mike Hommey wrote:\n> > \n> > >>> The reason for the :: prefix is that it matches the ::\n> > >>> prefix used for remote helpers.\n> > >>>\n> > >>> Now, there are a few caveats:\n> > [...]\n> > >>> - msys likes to completely fuck up command lines when they contain ::.\n> > >>> For remote helpers, the alternative that works is\n> > >>> :///etc.\n> > >>\n> > >> Hm --- is there a bug already open about this (e.g. in the Git for\n> > >> Windows project or in msys) where I can read more?\n> > >\n> > > It's entirely an msys problem. Msys has weird rules to translate between\n> > > unix paths and windows paths on the command line, and botches everything\n> > > as a consequence. That's by \"design\".\n> > >\n> > > http://www.mingw.org/wiki/Posix_path_conversion\n> > >\n> > > (Particularly, see the last two entries)\n> > >\n> > > That only happens when calling native Windows programs from a msys\n> > > shell.\n> > \n> > Cc-ing the Git for Windows mailing list as an FYI.\n> > \n> > I have faint memories that some developers on that project have had to\n> > delve deep into Msys path modification rules. It's possible they can\n> > give us advice (e.g. about :: having been a bad choice of\n> > syntax in the first place :)).\n> \n> I think it is safe to assume that :: is not part of any Unix-y path. That\n> is why the MSYS2 runtime does not try to play games with it by converting\n> it to a Windows path.\n> \n> (And indeed, I just tested this, an argument of the form\n> \"a::file://b/x/y/z\" is not converted to a \"Windows path\")\n\nNote that there are people out there using msys, *and* git for windows,\nalthough I don't know if such people exist outside Mozilla.\n\nMike\n"},{"id":"327180","messageId":"alpine.DEB.2.21.1.1708251258080.7424@virtualbox","threadId":"46621","inReplyTo":"20170824082350.6ed6jqkn6aeylvnv@glandium.org","subject":"Re: [git-for-windows] Re: Revision resolution for remote-helpers?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-25T10:58:52Z","receivedAt":"2017-08-25T10:59:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Mike,\n\nOn Thu, 24 Aug 2017, Mike Hommey wrote:\n\n> On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:\n> > \n> > On Fri, 18 Aug 2017, Jonathan Nieder wrote:\n> > \n> > > Mike Hommey wrote[1]:\n> > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n> > > >> Mike Hommey wrote:\n> > > \n> > > >>> The reason for the :: prefix is that it matches the ::\n> > > >>> prefix used for remote helpers.\n> > > >>>\n> > > >>> Now, there are a few caveats:\n> > > [...]\n> > > >>> - msys likes to completely fuck up command lines when they contain ::.\n> > > >>> For remote helpers, the alternative that works is\n> > > >>> :///etc.\n> > > >>\n> > > >> Hm --- is there a bug already open about this (e.g. in the Git for\n> > > >> Windows project or in msys) where I can read more?\n> > > >\n> > > > It's entirely an msys problem. Msys has weird rules to translate between\n> > > > unix paths and windows paths on the command line, and botches everything\n> > > > as a consequence. That's by \"design\".\n> > > >\n> > > > http://www.mingw.org/wiki/Posix_path_conversion\n> > > >\n> > > > (Particularly, see the last two entries)\n> > > >\n> > > > That only happens when calling native Windows programs from a msys\n> > > > shell.\n> > > \n> > > Cc-ing the Git for Windows mailing list as an FYI.\n> > > \n> > > I have faint memories that some developers on that project have had to\n> > > delve deep into Msys path modification rules. It's possible they can\n> > > give us advice (e.g. about :: having been a bad choice of\n> > > syntax in the first place :)).\n> > \n> > I think it is safe to assume that :: is not part of any Unix-y path. That\n> > is why the MSYS2 runtime does not try to play games with it by converting\n> > it to a Windows path.\n> > \n> > (And indeed, I just tested this, an argument of the form\n> > \"a::file://b/x/y/z\" is not converted to a \"Windows path\")\n> \n> Note that there are people out there using msys, *and* git for windows,\n> although I don't know if such people exist outside Mozilla.\n\nNote that I am maintainer of Git for Windows, not of any setup that uses\nMSys. Please do not even try to put more stuff on my plate.\n\nThanks,\nJohannes\n"},{"id":"327184","messageId":"20170825120236.orf6wubxf6qlvouy@glandium.org","threadId":"46621","inReplyTo":"alpine.DEB.2.21.1.1708251258080.7424@virtualbox","subject":"Re: [git-for-windows] Re: Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-08-25T12:02:36Z","receivedAt":"2017-08-25T12:02:51Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:\n> Hi Mike,\n> \n> On Thu, 24 Aug 2017, Mike Hommey wrote:\n> \n> > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:\n> > > \n> > > On Fri, 18 Aug 2017, Jonathan Nieder wrote:\n> > > \n> > > > Mike Hommey wrote[1]:\n> > > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:\n> > > > >> Mike Hommey wrote:\n> > > > \n> > > > >>> The reason for the :: prefix is that it matches the ::\n> > > > >>> prefix used for remote helpers.\n> > > > >>>\n> > > > >>> Now, there are a few caveats:\n> > > > [...]\n> > > > >>> - msys likes to completely fuck up command lines when they contain ::.\n> > > > >>> For remote helpers, the alternative that works is\n> > > > >>> :///etc.\n> > > > >>\n> > > > >> Hm --- is there a bug already open about this (e.g. in the Git for\n> > > > >> Windows project or in msys) where I can read more?\n> > > > >\n> > > > > It's entirely an msys problem. Msys has weird rules to translate between\n> > > > > unix paths and windows paths on the command line, and botches everything\n> > > > > as a consequence. That's by \"design\".\n> > > > >\n> > > > > http://www.mingw.org/wiki/Posix_path_conversion\n> > > > >\n> > > > > (Particularly, see the last two entries)\n> > > > >\n> > > > > That only happens when calling native Windows programs from a msys\n> > > > > shell.\n> > > > \n> > > > Cc-ing the Git for Windows mailing list as an FYI.\n> > > > \n> > > > I have faint memories that some developers on that project have had to\n> > > > delve deep into Msys path modification rules. It's possible they can\n> > > > give us advice (e.g. about :: having been a bad choice of\n> > > > syntax in the first place :)).\n> > > \n> > > I think it is safe to assume that :: is not part of any Unix-y path. That\n> > > is why the MSYS2 runtime does not try to play games with it by converting\n> > > it to a Windows path.\n> > > \n> > > (And indeed, I just tested this, an argument of the form\n> > > \"a::file://b/x/y/z\" is not converted to a \"Windows path\")\n> > \n> > Note that there are people out there using msys, *and* git for windows,\n> > although I don't know if such people exist outside Mozilla.\n> \n> Note that I am maintainer of Git for Windows, not of any setup that uses\n> MSys. Please do not even try to put more stuff on my plate.\n\nI'm not trying to do that. I'm just saying that there are setups where\nthe current way of using remote helpers doesn't work out, and it's\ncompletely independent of git or git for windows, and there's not much\ngit for windows can do about it except maybe unmangling what msys does,\nbut it's about as horrible as not doing anything.\n\nThis does bring the question, though, whether there should be an\nalternative syntax, which there actually is, but it doesn't really allow\nto convey things with a protocol after the double colons (e.g.\nyou can't really distinguish between hg::http://... and hg::http://...\nwith the hg:// form ; git-cinnabar allows the protocol to appear as part\nof the port number, e.g. hg://host:http/... and hg:// defaults to https)\n\nAnd this brings the question whether :: would be the right \"trigger\" for\nthe feature that opened this thread originally.\n\nMike\n"},{"id":"328517","messageId":"20170921011307.ktqwesbh5wuckl55@glandium.org","threadId":"46621","inReplyTo":"20170825120236.orf6wubxf6qlvouy@glandium.org","subject":"Re: [git-for-windows] Re: Revision resolution for remote-helpers?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2017-09-21T01:13:07Z","receivedAt":"2017-09-21T01:13:21Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote:\n> On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:\n> > > > > Cc-ing the Git for Windows mailing list as an FYI.\n> > > > > \n> > > > > I have faint memories that some developers on that project have had to\n> > > > > delve deep into Msys path modification rules. It's possible they can\n> > > > > give us advice (e.g. about :: having been a bad choice of\n> > > > > syntax in the first place :)).\n> > > > \n> > > > I think it is safe to assume that :: is not part of any Unix-y path. That\n> > > > is why the MSYS2 runtime does not try to play games with it by converting\n> > > > it to a Windows path.\n> > > > \n> > > > (And indeed, I just tested this, an argument of the form\n> > > > \"a::file://b/x/y/z\" is not converted to a \"Windows path\")\n> > > \n> > > Note that there are people out there using msys, *and* git for windows,\n> > > although I don't know if such people exist outside Mozilla.\n> > \n> > Note that I am maintainer of Git for Windows, not of any setup that uses\n> > MSys. Please do not even try to put more stuff on my plate.\n> \n> I'm not trying to do that. I'm just saying that there are setups where\n> the current way of using remote helpers doesn't work out, and it's\n> completely independent of git or git for windows, and there's not much\n> git for windows can do about it except maybe unmangling what msys does,\n> but it's about as horrible as not doing anything.\n> \n> This does bring the question, though, whether there should be an\n> alternative syntax, which there actually is, but it doesn't really allow\n> to convey things with a protocol after the double colons (e.g.\n> you can't really distinguish between hg::http://... and hg::http://...\n> with the hg:// form ; git-cinnabar allows the protocol to appear as part\n> of the port number, e.g. hg://host:http/... and hg:// defaults to https)\n> \n> And this brings the question whether :: would be the right \"trigger\" for\n> the feature that opened this thread originally.\n\n(FYI, FWIW)\n\nSo, interestingly, I tried using the instructions on\nhttps://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper\ntoday, and that led me to the same problem, being that the msys path\nmunging was breaking :: syntax.\n\nIt turns out, I had placed the git-for-windows section last in\npacman.conf, so msys2-runtime hadn't been updated. Once it is updated,\nthe :: syntax is not munged anymore, and everything works\nas expected.\n\nMeaning, in fact, that git-for-windows has addressed the problem on its\nend, but the problem still exists when running git-for-windows from a\nmsys2 shell without the git-for-windows msys2 runtime.\n\nAlso, the munging happens at the caller side, so the shell needs to be\nusing git-for-windows's msys2 runtime, it's not enough that git itself\ndoes.\n\nMike\n"}]}