Re: [git-for-windows] Re: Revision resolution for remote-helpers?
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 :: 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 :: 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 :: 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
Re: [git-for-windows] Re: Revision resolution for remote-helpers?
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 :: prefix is that it matches the > > > > >>> :: > > > > >>> 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 > > > > >>> :///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 :: 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?
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 :: prefix is that it matches the :: > > > >>> 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 > > > >>> :///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 :: 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?
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 :: prefix is that it matches the :: > > >>> 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 > > >>> :///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 :: 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?
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 :: prefix is that it matches the :: > >>> 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 > >>> :///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 :: 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
