Re: 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x

[Marc Strapetz]

On 29.06.2015 10:30, Johannes Schindelin wrote:
> I just uploaded the 4th release candidate for the upcoming Git for
> Windows 2.x release. Please find the download link here:

Where should problems with Git for Windows 2.x be reported?

What I've noticed is that Git for Windows 2.x builds seem to take
themselves from the PATH:

Consider to have Git installed at:

C:\Program Files (x86)\Git

and following test script located at C:\temp\path.sh:

#!/bin/bash
echo $PATH
git --version

Then, from terminal execution of the test script fails:

$ cd C:\Program Files (x86)\git
$ set path="C:\Program Files (x86)\Git\bin"
$ bin\bash c:\temp\path.sh
/bin/bin:/bin/mingw/bin:/bin
d:\temp\path.sh: line 4: git: command not found

But just when changing a part of the path to lower case, it's preserved
and the script succeeds:

$ set path="C:\Program Files (x86)\git\bin"
$ bin\bash c:\temp\path.sh
/bin/bin:/bin/mingw/bin:/c/Program Files (x86)/git/bin
git version 2.4.5.windows.1

Is this behavior expected?

-Marc

[Johannes Schindelin]

Hi Marc,

On 2015-07-16 14:34, Marc Strapetz wrote:
> On 29.06.2015 10:30, Johannes Schindelin wrote:
>> I just uploaded the 4th release candidate for the upcoming Git for
>> Windows 2.x release. Please find the download link here:
>
> Where should problems with Git for Windows 2.x be reported?

As mentioned in https://git-for-windows.github.io/, they should be
reported at https://github.com/git-for-windows/git/issues.

But via email is also fine; it is just a little harder to collect all
comments when discussing via mail. Not a big deal.

> What I've noticed is that Git for Windows 2.x builds seem to take
> themselves from the PATH:
>
> Consider to have Git installed at:
>
> C:\Program Files (x86)\Git
>
> and following test script located at C:\temp\path.sh:
>
> #!/bin/bash
> echo $PATH
> git --version
>
> Then, from terminal execution of the test script fails:
>
> $ cd C:\Program Files (x86)\git
> $ set path="C:\Program Files (x86)\Git\bin"
> $ bin\bash c:\temp\path.sh
> /bin/bin:/bin/mingw/bin:/bin
> d:\temp\path.sh: line 4: git: command not found
>
> But just when changing a part of the path to lower case, it's
> preserved and the script succeeds:
>
> $ set path="C:\Program Files (x86)\git\bin"
> $ bin\bash c:\temp\path.sh
> /bin/bin:/bin/mingw/bin:/c/Program Files (x86)/git/bin
> git version 2.4.5.windows.1
>
> Is this behavior expected?

No, something spooky is going on there.

Does it still do that if you call `set PATH=...`?

Ciao,
Johannes

[Marc Strapetz]

Hi Johannes,

On 16.07.2015 14:59, Johannes Schindelin wrote:
> Hi Marc,
>
> On 2015-07-16 14:34, Marc Strapetz wrote:
>> On 29.06.2015 10:30, Johannes Schindelin wrote:
>>> I just uploaded the 4th release candidate for the upcoming Git for
>>> Windows 2.x release. Please find the download link here:
>>
>> Where should problems with Git for Windows 2.x be reported?
>
> As mentioned in https://git-for-windows.github.io/, they should be
> reported at https://github.com/git-for-windows/git/issues.

OK, I will do so for further issues (if any).

>> $ set path="C:\Program Files (x86)\git\bin"
>> $ bin\bash c:\temp\path.sh
>> /bin/bin:/bin/mingw/bin:/c/Program Files (x86)/git/bin
>> git version 2.4.5.windows.1
>>
>> Is this behavior expected?
>
> No, something spooky is going on there.
>
> Does it still do that if you call `set PATH=...`?

You mean using upper-case "PATH" instead of lower-case "path"? This
makes no difference. Also, skipping double-quotes does not matter.

I'm using the portable bundle, if this matters. And just to avoid
confusion, I've been executing all commands from DOS command line (the
'$' should just represent the DOS prompt).

Is there something else I could try? Are there some debug options I
could enable?

-Marc

[Johannes Schindelin]

Hi all,

I just uploaded the 5th release candidate for the upcoming Git for

Windows 2.x release. Please find the download link here:

https://git-for-windows.github.io/#download



Apart from synchronizing with Git 2.4.6, this version brings the following fixes:

* Git for Windows handles symlinks now, even if core.symlinks does not tell Git to generate symlinks itself.
* git svn learned not to reuse incompatible on-disk caches left over from previous Git for Windows versions.

Please find the release notes here:

https://github.com/git-for-windows/build-extra/blob/master/installer/ReleaseNotes.md

There is at least one bigger issue I still want to address, therefore there will most likely be another release candidate soon, but I simply did not want to force the fans to wait for 2.4.6 and the two bug fixes.

Ciao,
Johannes

[Johannes Schindelin]

Hi Marc,

On 2015-07-16 21:47, Marc Strapetz wrote:
> On 16.07.2015 14:59, Johannes Schindelin wrote:
>> On 2015-07-16 14:34, Marc Strapetz wrote:
>>
>>> $ set path="C:\Program Files (x86)\git\bin"
>>> $ bin\bash c:\temp\path.sh
>>> /bin/bin:/bin/mingw/bin:/c/Program Files (x86)/git/bin
>>> git version 2.4.5.windows.1
>>>
>>> Is this behavior expected?

I *just* had time to reproduce the problem.

There are multiple things going on and all of them are important, so
hang on for a while.

The first thing to note is that I made a conscious decision with Git for
Windows 1.x to just slam every executable into /bin/ and be done with
it. This breaks the paradigm of MinGW, though, which makes a very clear
distinction between MinGW executables (i.e. programs using the pure
Win32 API) and MSys executables (i.e. programs relying on the POSIX
emulation of MSys). The former are expected to be in /mingw/bin/ and the
latter in /bin/ for MSys1 (on which Git for Windows 1.x is based).

This was a mistake and the major version jump to 2.x gave me an
excellent opportunity to fix it. Now it is even more complicated,
though: there are *three* bin/ directories: /usr/bin/ for MSys2
executables, /mingw32/bin/ and /mingw64/bin/ for 32-bit and 64-bit
executables, respectively, that do not rely on the POSIX emulation. It
is not possible to mix and match 32-bit and 64-bit MSys2 programs,
though.

For 32-bit Git for Windows, I opted to stay with an all 32-bit
environment, so all the MinGW executables are in /mingw32/bin/. For
64-bit, consequently, they live in /mingw64/bin/.

Now, for backwards-compatibility, I introduced what I call "redirectors"
into the /bin/ directory of Git for Windows 2.x. There is `git.exe`,
`bash.exe` and `sh.exe` in this directory, and nothing else. And those
executables are not the "real things", either: they just execute the
real executables in the correct places, wait for them to exit and then
exit with the same exit status.

So far, so good.

But now when you call `bash`, it auto-mounts /usr/bin/ as /bin/ and
therefore the `git.exe` is not found on the PATH because there is only
/bin/ and /mingw/bin/ (which does not even exist in MSys2) in the PATH.
By the way, /bin/:/mingw/bin/ are prefixed automatically by the MSys2
Bash. The rest of the PATH is translated into POSIX-style paths if
possible.

And that is where the subtle issue lies: if the case matches *exactly*,
then your C:\Program Files (x86)\Git\bin gets translated into /bin/.
Which would be fine... if not for that auto-mount! If you misspell the
path ever so slightly (as far as POSIX is concerned, case mismatches are
real spelling errors), the path gets translated into /c/Program\ Files\
\(x86\)/Git/bin instead... which is not shadowed by that auto-mount!

So you have (at least) two options to handle this:

- you could call `bash --login c:\temp\test.sh`. This will add the
/mingw32/bin/ directory to the PATH and everything works.

- you could set the PATH to C:\Program Files
(x86)\Git\mingw32\bin;C:\Program Files (x86)\usr\bin. Those are the
*correct* locations, i.e. not the /bin/ directory that contains only
redirectors.

You could also just misspell the path ;-)

There are of course a couple more options, even some I would prefer but
they would require a substantial amount of work on your side... Let me
know if you are up for working on some Pull Requests ;-)

Ciao,
Johannes

[Marc Strapetz]

Hello Johannes,

On 07.08.2015 17:33, Johannes Schindelin wrote:
> ...

>
> But now when you call `bash`, it auto-mounts /usr/bin/ as /bin/ and
> therefore the `git.exe` is not found on the PATH because there is only
> /bin/ and /mingw/bin/ (which does not even exist in MSys2) in the PATH.
> By the way, /bin/:/mingw/bin/ are prefixed automatically by the MSys2
> Bash. The rest of the PATH is translated into POSIX-style paths if
> possible.
>
> And that is where the subtle issue lies: if the case matches *exactly*,
> then your C:\Program Files (x86)\Git\bin gets translated into /bin/.
> Which would be fine... if not for that auto-mount! If you misspell the
> path ever so slightly (as far as POSIX is concerned, case mismatches are
> real spelling errors), the path gets translated into /c/Program\ Files\
> \(x86\)/Git/bin instead... which is not shadowed by that auto-mount!
>
> So you have (at least) two options to handle this:
>
> - you could call `bash --login c:\temp\test.sh`. This will add the
> /mingw32/bin/ directory to the PATH and everything works.
>
> - you could set the PATH to C:\Program Files
> (x86)\Git\mingw32\bin;C:\Program Files (x86)\usr\bin. Those are the
> *correct* locations, i.e. not the /bin/ directory that contains only
> redirectors.

Thanks for your detailed explanation. I've opted for this second
approach now and can confirm that our bash scripts are working.

-Marc