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
