Revision resolution for remote-helpers?

Revision resolution for remote-helpers?

[Mike Hommey]

Hi,

As you might remember, I'm maintaining a remote helper that allows to
talk directly to mercurial servers with git: git-cinnabar.

When dealing with "foreign (non-git) repositories", it is often
necessary to refer to revisions with their native name. With mercurial,
that's a sha1, with svn it's a revision number, etc.

Git-cinnabar does provide a helper command that gives back the git
commit from the mercurial revision (and vice versa), but that's
cumbersome to use in commands.

I was thinking it could be useful to have a special syntax for revisions
that would query a helper program. The helper program could use a
similar protocol to that of the remote helpers.

My thought is that a string like <helper>::<revision> could be used
wherever a committish is expected. That would call some helper
and request to resolve revision, and the helper would provide a git
commit as a response.

The reason for the <helper>:: prefix is that it matches the <helper>::
prefix used for remote helpers.

Now, there are a few caveats:
- <revision>, for e.g. svn, pretty much would depend on the remote.
  OTOH, in mercurial, it doesn't. I think it would be fair for the
  helper to have to deal with making what appears after :: relevant
  to find the right revision, by possibly including a remote name.
- msys likes to completely fuck up command lines when they contain ::.
  For remote helpers, the alternative that works is
  <helper>://<host>/etc.

Which leads me to think some "virtual" ref namespace could be a solution
to the problem. So instead of <helper>::, the prefix would be <helper>/.
For e.g. svn, svn/$remote/$rev would be a natural way to specify the
revision for a given remote. For mercurial, hg/$sha1.

Potentially, this could be a sort of pluggable ref stores, which could
be used for extensions such as the currently discussed reftable.

On the opposite end of the problem, I'm also thinking about git log
--decorate=<helper> displaying the mercurial revisions where branch
decorations would normally go.

I have no patch to show for it. Those are ideas that I first want to
discuss before implementing anything.

Thoughts?

Mike

Re: Revision resolution for remote-helpers?

[Jeff King]

On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:

> I was thinking it could be useful to have a special syntax for revisions
> that would query a helper program. The helper program could use a
> similar protocol to that of the remote helpers.

That sounds like a reasonable thing to want.

> My thought is that a string like <helper>::<revision> could be used
> wherever a committish is expected. That would call some helper
> and request to resolve revision, and the helper would provide a git
> commit as a response.

So I'm guessing this would look something like:

  git log svn::12345

I think even without Git support, you could do something like:

  git log $(git svn map 12345)

which is similarly complex in terms of concepts, and not too many more
characters. That would be a little more awkward outside of a shell,
though.

But it did get me wondering if we could do _better_ with something built
into Git. For example, could we have an external resolution helper that
resolves names to object ids as a fallback after internal resolution has
failed. And then you could do:

 git log 12345

and it would just work. Efficiency shouldn't be a big problem, because
we'd hit the helper only in the error case.

I'd be more concerned about awkward ambiguities, though. If mercurial is
also using sha1s, then there's nothing syntactic to differentiate the
two. For that matter, 12345 has the same problem, since it could be a
partial sha1.

It might work to actually check if we have the object and then bail
to the remote resolver only if we don't. But that's actually conflating
name resolution with object lookup, which our internals typically keep
separate.

So maybe this is a bad direction to go in. I'm mostly just thinking out
loud here.

> Which leads me to think some "virtual" ref namespace could be a solution
> to the problem. So instead of <helper>::, the prefix would be <helper>/.
> For e.g. svn, svn/$remote/$rev would be a natural way to specify the
> revision for a given remote. For mercurial, hg/$sha1.

Interesting. I do like the general idea of having external helpers to
fill in bits of the virtual namespace. But it may also open many cans of
worms. :)

> Potentially, this could be a sort of pluggable ref stores, which could
> be used for extensions such as the currently discussed reftable.

The current pluggable code is definitely geared for build-time
pluggability, not runtime. But I think you could have a builtin
pluggable store that does the overlay, and then chains to another
backend. I.e., configure something like:

  [extensions]
  refBackend = externalOverlay

  [externalOverlay "svn"]
  namespace = refs/svn
  command = my-svn-mapper

  [externalOverlay]
  chain = reftable

That would allow the externalOverlay thing to develop independent of the
core of Git's refs code.

> On the opposite end of the problem, I'm also thinking about git log
> --decorate=<helper> displaying the mercurial revisions where branch
> decorations would normally go.

Interesting thought. I'm not sure if that would be a good thing or a bad
thing. But one of the virtual methods for pluggable backends is
"enumerate all refs". If you're mapping every mercurial revision, that's
going to be a lot of refs (and potentially a lot of overhead for certain
operations).

I think the decorate code just looks at a few parts of the refs
namespace right now (so a "refs/svn" would probably get ignored by
default).

-Peff

Re: Revision resolution for remote-helpers?

[Mike Hommey]

On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote:
> On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:
> 
> > I was thinking it could be useful to have a special syntax for revisions
> > that would query a helper program. The helper program could use a
> > similar protocol to that of the remote helpers.
> 
> That sounds like a reasonable thing to want.
> 
> > My thought is that a string like <helper>::<revision> could be used
> > wherever a committish is expected. That would call some helper
> > and request to resolve revision, and the helper would provide a git
> > commit as a response.
> 
> So I'm guessing this would look something like:
> 
>   git log svn::12345
> 
> I think even without Git support, you could do something like:
> 
>   git log $(git svn map 12345)

That's what I do, but subshells and all is extra cumbersome.

> which is similarly complex in terms of concepts, and not too many more
> characters. That would be a little more awkward outside of a shell,
> though.
> 
> But it did get me wondering if we could do _better_ with something built
> into Git. For example, could we have an external resolution helper that
> resolves names to object ids as a fallback after internal resolution has
> failed. And then you could do:
> 
>  git log 12345
> 
> and it would just work. Efficiency shouldn't be a big problem, because
> we'd hit the helper only in the error case.
> 
> I'd be more concerned about awkward ambiguities, though. If mercurial is
> also using sha1s, then there's nothing syntactic to differentiate the
> two. For that matter, 12345 has the same problem, since it could be a
> partial sha1.

For something as short, the likelihood of hitting an actual existing
abbreviated sha1 is quite high, too.

> It might work to actually check if we have the object and then bail
> to the remote resolver only if we don't. But that's actually conflating
> name resolution with object lookup, which our internals typically keep
> separate.
> 
> So maybe this is a bad direction to go in. I'm mostly just thinking out
> loud here.
> 
> > Which leads me to think some "virtual" ref namespace could be a solution
> > to the problem. So instead of <helper>::, the prefix would be <helper>/.
> > For e.g. svn, svn/$remote/$rev would be a natural way to specify the
> > revision for a given remote. For mercurial, hg/$sha1.
> 
> Interesting. I do like the general idea of having external helpers to
> fill in bits of the virtual namespace. But it may also open many cans of
> worms. :)
> 
> > Potentially, this could be a sort of pluggable ref stores, which could
> > be used for extensions such as the currently discussed reftable.
> 
> The current pluggable code is definitely geared for build-time
> pluggability, not runtime. But I think you could have a builtin
> pluggable store that does the overlay, and then chains to another
> backend. I.e., configure something like:
> 
>   [extensions]
>   refBackend = externalOverlay
> 
>   [externalOverlay "svn"]
>   namespace = refs/svn
>   command = my-svn-mapper
> 
>   [externalOverlay]
>   chain = reftable
> 
> That would allow the externalOverlay thing to develop independent of the
> core of Git's refs code.

That's a lot of configuration, but it's definitely an interesting
proposition.

> > On the opposite end of the problem, I'm also thinking about git log
> > --decorate=<helper> displaying the mercurial revisions where branch
> > decorations would normally go.
> 
> Interesting thought. I'm not sure if that would be a good thing or a bad
> thing. But one of the virtual methods for pluggable backends is
> "enumerate all refs". If you're mapping every mercurial revision, that's
> going to be a lot of refs (and potentially a lot of overhead for certain
> operations).
> 
> I think the decorate code just looks at a few parts of the refs
> namespace right now (so a "refs/svn" would probably get ignored by
> default).

I think decorate would need its own special entry to the "ref query" API
to answer the question "what ref points to <sha1>" instead of scanning
the whole namespace.

Mike

Re: Revision resolution for remote-helpers?

[Jonathan Nieder]

Hi,

Mike Hommey wrote:

> My thought is that a string like <helper>::<revision> could be used
> wherever a committish is expected. That would call some helper
> and request to resolve revision, and the helper would provide a git
> commit as a response.

I like this idea.

> The reason for the <helper>:: prefix is that it matches the <helper>::
> prefix used for remote helpers.
>
> Now, there are a few caveats:
> - <revision>, for e.g. svn, pretty much would depend on the remote.
>   OTOH, in mercurial, it doesn't. I think it would be fair for the
>   helper to have to deal with making what appears after :: relevant
>   to find the right revision, by possibly including a remote name.
> - msys likes to completely fuck up command lines when they contain ::.
>   For remote helpers, the alternative that works is
>   <helper>://<host>/etc.

Hm --- is there a bug already open about this (e.g. in the Git for
Windows project or in msys) where I can read more?

> Which leads me to think some "virtual" ref namespace could be a solution
> to the problem. So instead of <helper>::, the prefix would be <helper>/.
> For e.g. svn, svn/$remote/$rev would be a natural way to specify the
> revision for a given remote. For mercurial, hg/$sha1.

I see.  My naive assumption would be that a string like r12345 would be
the most natural way for a user to want to specify a Subversion
revision, but you're right that those only have meaning scoped to a
particular server.  That makes the svn/ prefix more tolerable.

> Potentially, this could be a sort of pluggable ref stores, which could
> be used for extensions such as the currently discussed reftable.
>
> On the opposite end of the problem, I'm also thinking about git log
> --decorate=<helper> displaying the mercurial revisions where branch
> decorations would normally go.
>
> I have no patch to show for it. Those are ideas that I first want to
> discuss before implementing anything.

One additional thought: unlike refs, these are not necessarily
enumerable (and I wouldn't expect "git show-ref" to show them) and
they do not affect "git prune"'s reachability computation.

So internally I don't think refs is the right concept to map these to.
I think the right layer is revision syntax handling (revision.c).

Thanks,
Jonathan

Re: Revision resolution for remote-helpers?

[Mike Hommey]

On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> Hi,
> 
> Mike Hommey wrote:
> 
> > My thought is that a string like <helper>::<revision> could be used
> > wherever a committish is expected. That would call some helper
> > and request to resolve revision, and the helper would provide a git
> > commit as a response.
> 
> I like this idea.
> 
> > The reason for the <helper>:: prefix is that it matches the <helper>::
> > prefix used for remote helpers.
> >
> > Now, there are a few caveats:
> > - <revision>, for e.g. svn, pretty much would depend on the remote.
> >   OTOH, in mercurial, it doesn't. I think it would be fair for the
> >   helper to have to deal with making what appears after :: relevant
> >   to find the right revision, by possibly including a remote name.
> > - msys likes to completely fuck up command lines when they contain ::.
> >   For remote helpers, the alternative that works is
> >   <helper>://<host>/etc.
> 
> Hm --- is there a bug already open about this (e.g. in the Git for
> Windows project or in msys) where I can read more?

It's entirely an msys problem. Msys has weird rules to translate between
unix paths and windows paths on the command line, and botches everything
as a consequence. That's by "design".

http://www.mingw.org/wiki/Posix_path_conversion

(Particularly, see the last two entries)

That only happens when calling native Windows programs from a msys
shell.

> > Which leads me to think some "virtual" ref namespace could be a solution
> > to the problem. So instead of <helper>::, the prefix would be <helper>/.
> > For e.g. svn, svn/$remote/$rev would be a natural way to specify the
> > revision for a given remote. For mercurial, hg/$sha1.
> 
> I see.  My naive assumption would be that a string like r12345 would be
> the most natural way for a user to want to specify a Subversion
> revision, but you're right that those only have meaning scoped to a
> particular server.  That makes the svn/ prefix more tolerable.
> 
> > Potentially, this could be a sort of pluggable ref stores, which could
> > be used for extensions such as the currently discussed reftable.
> >
> > On the opposite end of the problem, I'm also thinking about git log
> > --decorate=<helper> displaying the mercurial revisions where branch
> > decorations would normally go.
> >
> > I have no patch to show for it. Those are ideas that I first want to
> > discuss before implementing anything.
> 
> One additional thought: unlike refs, these are not necessarily
> enumerable (and I wouldn't expect "git show-ref" to show them) and
> they do not affect "git prune"'s reachability computation.
> 
> So internally I don't think refs is the right concept to map these to.
> I think the right layer is revision syntax handling (revision.c).

Makes sense.

Mike

Re: Revision resolution for remote-helpers?

[Jonathan Nieder]

Mike Hommey wrote[1]:
> On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
>> Mike Hommey wrote:

>>> The reason for the <helper>:: prefix is that it matches the <helper>::
>>> prefix used for remote helpers.
>>>
>>> Now, there are a few caveats:
[...]
>>> - msys likes to completely fuck up command lines when they contain ::.
>>>   For remote helpers, the alternative that works is
>>>   <helper>://<host>/etc.
>>
>> Hm --- is there a bug already open about this (e.g. in the Git for
>> Windows project or in msys) where I can read more?
>
> It's entirely an msys problem. Msys has weird rules to translate between
> unix paths and windows paths on the command line, and botches everything
> as a consequence. That's by "design".
>
> http://www.mingw.org/wiki/Posix_path_conversion
>
> (Particularly, see the last two entries)
>
> That only happens when calling native Windows programs from a msys
> shell.

Cc-ing the Git for Windows mailing list as an FYI.

I have faint memories that some developers on that project have had to
delve deep into Msys path modification rules.  It's possible they can
give us advice (e.g. about <helper>::<url> having been a bad choice of
syntax in the first place :)).

Thanks,
Jonathan

[1] https://public-inbox.org/git/20170818221754.3rbh35aewj5xnu4z@glandium.org/

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

[Johannes Schindelin]

Hi,

On Fri, 18 Aug 2017, Jonathan Nieder wrote:

> Mike Hommey wrote[1]:
> > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> >> Mike Hommey wrote:
> 
> >>> The reason for the <helper>:: prefix is that it matches the <helper>::
> >>> prefix used for remote helpers.
> >>>
> >>> Now, there are a few caveats:
> [...]
> >>> - msys likes to completely fuck up command lines when they contain ::.
> >>>   For remote helpers, the alternative that works is
> >>>   <helper>://<host>/etc.
> >>
> >> Hm --- is there a bug already open about this (e.g. in the Git for
> >> Windows project or in msys) where I can read more?
> >
> > It's entirely an msys problem. Msys has weird rules to translate between
> > unix paths and windows paths on the command line, and botches everything
> > as a consequence. That's by "design".
> >
> > http://www.mingw.org/wiki/Posix_path_conversion
> >
> > (Particularly, see the last two entries)
> >
> > That only happens when calling native Windows programs from a msys
> > shell.
> 
> Cc-ing the Git for Windows mailing list as an FYI.
> 
> I have faint memories that some developers on that project have had to
> delve deep into Msys path modification rules.  It's possible they can
> give us advice (e.g. about <helper>::<url> having been a bad choice of
> syntax in the first place :)).

I think it is safe to assume that :: is not part of any Unix-y path. That
is why the MSYS2 runtime does not try to play games with it by converting
it to a Windows path.

(And indeed, I just tested this, an argument of the form
"a::file://b/x/y/z" is not converted to a "Windows path")

Ciao,
Dscho

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

[Mike Hommey]

On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> 
> > Mike Hommey wrote[1]:
> > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> > >> Mike Hommey wrote:
> > 
> > >>> The reason for the <helper>:: prefix is that it matches the <helper>::
> > >>> prefix used for remote helpers.
> > >>>
> > >>> Now, there are a few caveats:
> > [...]
> > >>> - msys likes to completely fuck up command lines when they contain ::.
> > >>>   For remote helpers, the alternative that works is
> > >>>   <helper>://<host>/etc.
> > >>
> > >> Hm --- is there a bug already open about this (e.g. in the Git for
> > >> Windows project or in msys) where I can read more?
> > >
> > > It's entirely an msys problem. Msys has weird rules to translate between
> > > unix paths and windows paths on the command line, and botches everything
> > > as a consequence. That's by "design".
> > >
> > > http://www.mingw.org/wiki/Posix_path_conversion
> > >
> > > (Particularly, see the last two entries)
> > >
> > > That only happens when calling native Windows programs from a msys
> > > shell.
> > 
> > Cc-ing the Git for Windows mailing list as an FYI.
> > 
> > I have faint memories that some developers on that project have had to
> > delve deep into Msys path modification rules.  It's possible they can
> > give us advice (e.g. about <helper>::<url> having been a bad choice of
> > syntax in the first place :)).
> 
> I think it is safe to assume that :: is not part of any Unix-y path. That
> is why the MSYS2 runtime does not try to play games with it by converting
> it to a Windows path.
> 
> (And indeed, I just tested this, an argument of the form
> "a::file://b/x/y/z" is not converted to a "Windows path")

Note that there are people out there using msys, *and* git for windows,
although I don't know if such people exist outside Mozilla.

Mike

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

[Johannes Schindelin]

Hi Mike,

On Thu, 24 Aug 2017, Mike Hommey wrote:

> On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> > 
> > On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> > 
> > > Mike Hommey wrote[1]:
> > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> > > >> Mike Hommey wrote:
> > > 
> > > >>> The reason for the <helper>:: prefix is that it matches the <helper>::
> > > >>> prefix used for remote helpers.
> > > >>>
> > > >>> Now, there are a few caveats:
> > > [...]
> > > >>> - msys likes to completely fuck up command lines when they contain ::.
> > > >>>   For remote helpers, the alternative that works is
> > > >>>   <helper>://<host>/etc.
> > > >>
> > > >> Hm --- is there a bug already open about this (e.g. in the Git for
> > > >> Windows project or in msys) where I can read more?
> > > >
> > > > It's entirely an msys problem. Msys has weird rules to translate between
> > > > unix paths and windows paths on the command line, and botches everything
> > > > as a consequence. That's by "design".
> > > >
> > > > http://www.mingw.org/wiki/Posix_path_conversion
> > > >
> > > > (Particularly, see the last two entries)
> > > >
> > > > That only happens when calling native Windows programs from a msys
> > > > shell.
> > > 
> > > Cc-ing the Git for Windows mailing list as an FYI.
> > > 
> > > I have faint memories that some developers on that project have had to
> > > delve deep into Msys path modification rules.  It's possible they can
> > > give us advice (e.g. about <helper>::<url> having been a bad choice of
> > > syntax in the first place :)).
> > 
> > I think it is safe to assume that :: is not part of any Unix-y path. That
> > is why the MSYS2 runtime does not try to play games with it by converting
> > it to a Windows path.
> > 
> > (And indeed, I just tested this, an argument of the form
> > "a::file://b/x/y/z" is not converted to a "Windows path")
> 
> Note that there are people out there using msys, *and* git for windows,
> although I don't know if such people exist outside Mozilla.

Note that I am maintainer of Git for Windows, not of any setup that uses
MSys. Please do not even try to put more stuff on my plate.

Thanks,
Johannes

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

[Mike Hommey]

On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:
> Hi Mike,
> 
> On Thu, 24 Aug 2017, Mike Hommey wrote:
> 
> > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> > > 
> > > On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> > > 
> > > > Mike Hommey wrote[1]:
> > > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> > > > >> Mike Hommey wrote:
> > > > 
> > > > >>> The reason for the <helper>:: prefix is that it matches the <helper>::
> > > > >>> prefix used for remote helpers.
> > > > >>>
> > > > >>> Now, there are a few caveats:
> > > > [...]
> > > > >>> - msys likes to completely fuck up command lines when they contain ::.
> > > > >>>   For remote helpers, the alternative that works is
> > > > >>>   <helper>://<host>/etc.
> > > > >>
> > > > >> Hm --- is there a bug already open about this (e.g. in the Git for
> > > > >> Windows project or in msys) where I can read more?
> > > > >
> > > > > It's entirely an msys problem. Msys has weird rules to translate between
> > > > > unix paths and windows paths on the command line, and botches everything
> > > > > as a consequence. That's by "design".
> > > > >
> > > > > http://www.mingw.org/wiki/Posix_path_conversion
> > > > >
> > > > > (Particularly, see the last two entries)
> > > > >
> > > > > That only happens when calling native Windows programs from a msys
> > > > > shell.
> > > > 
> > > > Cc-ing the Git for Windows mailing list as an FYI.
> > > > 
> > > > I have faint memories that some developers on that project have had to
> > > > delve deep into Msys path modification rules.  It's possible they can
> > > > give us advice (e.g. about <helper>::<url> having been a bad choice of
> > > > syntax in the first place :)).
> > > 
> > > I think it is safe to assume that :: is not part of any Unix-y path. That
> > > is why the MSYS2 runtime does not try to play games with it by converting
> > > it to a Windows path.
> > > 
> > > (And indeed, I just tested this, an argument of the form
> > > "a::file://b/x/y/z" is not converted to a "Windows path")
> > 
> > Note that there are people out there using msys, *and* git for windows,
> > although I don't know if such people exist outside Mozilla.
> 
> Note that I am maintainer of Git for Windows, not of any setup that uses
> MSys. Please do not even try to put more stuff on my plate.

I'm not trying to do that. I'm just saying that there are setups where
the current way of using remote helpers doesn't work out, and it's
completely independent of git or git for windows, and there's not much
git for windows can do about it except maybe unmangling what msys does,
but it's about as horrible as not doing anything.

This does bring the question, though, whether there should be an
alternative syntax, which there actually is, but it doesn't really allow
to convey things with a protocol after the double colons (e.g.
you can't really distinguish between hg::http://... and hg::http://...
with the hg:// form ; git-cinnabar allows the protocol to appear as part
of the port number, e.g. hg://host:http/... and hg:// defaults to https)

And this brings the question whether :: would be the right "trigger" for
the feature that opened this thread originally.

Mike

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

[Mike Hommey]

On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote:
> On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:
> > > > > Cc-ing the Git for Windows mailing list as an FYI.
> > > > > 
> > > > > I have faint memories that some developers on that project have had to
> > > > > delve deep into Msys path modification rules.  It's possible they can
> > > > > give us advice (e.g. about <helper>::<url> having been a bad choice of
> > > > > syntax in the first place :)).
> > > > 
> > > > I think it is safe to assume that :: is not part of any Unix-y path. That
> > > > is why the MSYS2 runtime does not try to play games with it by converting
> > > > it to a Windows path.
> > > > 
> > > > (And indeed, I just tested this, an argument of the form
> > > > "a::file://b/x/y/z" is not converted to a "Windows path")
> > > 
> > > Note that there are people out there using msys, *and* git for windows,
> > > although I don't know if such people exist outside Mozilla.
> > 
> > Note that I am maintainer of Git for Windows, not of any setup that uses
> > MSys. Please do not even try to put more stuff on my plate.
> 
> I'm not trying to do that. I'm just saying that there are setups where
> the current way of using remote helpers doesn't work out, and it's
> completely independent of git or git for windows, and there's not much
> git for windows can do about it except maybe unmangling what msys does,
> but it's about as horrible as not doing anything.
> 
> This does bring the question, though, whether there should be an
> alternative syntax, which there actually is, but it doesn't really allow
> to convey things with a protocol after the double colons (e.g.
> you can't really distinguish between hg::http://... and hg::http://...
> with the hg:// form ; git-cinnabar allows the protocol to appear as part
> of the port number, e.g. hg://host:http/... and hg:// defaults to https)
> 
> And this brings the question whether :: would be the right "trigger" for
> the feature that opened this thread originally.

(FYI, FWIW)

So, interestingly, I tried using the instructions on
https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper
today, and that led me to the same problem, being that the msys path
munging was breaking <helper>::<url> syntax.

It turns out, I had placed the git-for-windows section last in
pacman.conf, so msys2-runtime hadn't been updated. Once it is updated,
the <helper>::<url> syntax is not munged anymore, and everything works
as expected.

Meaning, in fact, that git-for-windows has addressed the problem on its
end, but the problem still exists when running git-for-windows from a
msys2 shell without the git-for-windows msys2 runtime.

Also, the munging happens at the caller side, so the shell needs to be
using git-for-windows's msys2 runtime, it's not enough that git itself
does.

Mike