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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux