threads / discuss / 46621

Revision resolution for remote-helpers?

Subject: Revision resolution for remote-helpers?

## tl;dr

11 messages between Aug 18, 2017 and Sep 21, 2017.

replies: 10people: 4as markdown or json

Mike Hommey· Aug 18, 2017, 06:42 UTC · lore
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
Jeff King· Aug 18, 2017, 12:15 UTC · re: Mike Hommey · lore

Re: Revision resolution for remote-helpers?

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
Mike Hommey· Aug 18, 2017, 21:57 UTC · re: Jeff King · lore

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote:
Show 20 quoted lines
> 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.
Show 18 quoted lines
> 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.

Show 37 quoted lines
> 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.

Show 13 quoted lines
> > 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
Jonathan Nieder· Aug 18, 2017, 22:06 UTC · re: Mike Hommey · lore

Re: Revision resolution for remote-helpers?

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.
Show 11 quoted lines
> 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.

Show 9 quoted lines
> 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

Mike Hommey· Aug 18, 2017, 22:17 UTC · re: Jonathan Nieder · lore

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
Show 25 quoted lines
> 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.

Show 26 quoted lines
> > 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
Jonathan Nieder· Aug 18, 2017, 22:33 UTC · re: Mike Hommey · lore

Re: Revision resolution for remote-helpers?

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:
[...]
Show 17 quoted lines
>>> - 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/
Johannes Schindelin· Aug 22, 2017, 20:15 UTC · re: Jonathan Nieder · lore

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

Hi,
On Fri, 18 Aug 2017, Jonathan Nieder wrote:
Show 33 quoted lines
> 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

Mike Hommey· Aug 24, 2017, 08:23 UTC · re: Johannes Schindelin · lore

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

On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
Show 44 quoted lines
> 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
Johannes Schindelin· Aug 25, 2017, 10:58 UTC · re: Mike Hommey · lore

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

Hi Mike,
On Thu, 24 Aug 2017, Mike Hommey wrote:
Show 47 quoted lines
> 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

Mike Hommey· Aug 25, 2017, 12:02 UTC · re: Johannes Schindelin · lore

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

On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:
Show 54 quoted lines
> 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
Mike Hommey· Sep 21, 2017, 01:13 UTC · re: Mike Hommey · lore

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

On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote:
Show 36 quoted lines
> 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

← back to recent threads