Release candidate of Git for Windows 2.x is out

[Johannes Schindelin]

Hi all,

I just uploaded release candidates for the upcoming Git for Windows 2.x release. Please find the download link here:

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

There are 32-bit and 64-bit versions both of regular installers and portable installers ("portable" meaning that they are .7z archives that can be unpacked anywhere and run in place, without any need for running an installer).

My projected time line is to hammer out the last kinks until Friday, and then continue after a one-week leave, if needed, and then finally retire msysGit and start the official 2.x release cycle of Git for Windows.

If you are running Windows and have a little time to spare, please test this release candidate thoroughly. If you find bugs, please first look at https://github.com/git-for-windows/git/issues (even the closed ones), and comment either on existing tickets or open new ones. It would be even cooler, of course, if you could open Pull Requests with fixes :-)

Ciao,
Johannes

[Johannes Schindelin]

Hi,

On 2015-06-09 10:43, Qb wrote:

> I'm trying the release candidate on Win 8.1. Everything's working now, but
> when I clone a repository
>
> git clone http://...../name.git CustomFolder
>
> it creates CustomFolder with the checkout files, but the .git folder is
> created inside CustomFolder\CustomFolder\

I cannot reproduce this behavior.

This is what I did to test:

1. install Git-2.4.2.1-release-candidate-64.exe (default options)
2. run Git Bash
3. git clone https://github.com/dscho/images.git octocats

This results in a correct checkout: `$HOME/octocats/.git/` exists and contains the local repository.

Ciao,
Johannes

[Johannes Schindelin]

Hi,

On 2015-06-09 14:10, QbProg wrote:

> I reproduce it using the windows command prompt (cmd.exe) using any
> repository. I tryed with bash and it works correctly.

Please note that you removed enough context that the mail does not make sense anymore if read individually.

At this point it might be best to open a ticket, as I suggested in my announcement: just log into GitHub (or sign up for free) and direct your web browser to https://github.com/git-for-windows/git/issues/new.

For the record: I tried again, with `Git CMD`, this time I called

```cmd
git clone https://github.com/dscho/images.git octo2
```

... and octo2/ is created correctly and contains the `.git/` subdirectory (which is hidden by default, but you can call `cd octo2/.git`). Read: I still cannot reproduce the issue.

Ciao,
Johannes

[Johannes Schindelin]

Hi all,

I just uploaded the 3rd release candidate for the upcoming Git for Windows 2.x release. Please find the download link here:

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

Lots of changes since the first release candidate (v2.4.2, I was too swamped to announce the second release candidate -- v2.4.3 -- I published Friday last week, my apologies). Please find them in the release notes:

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

We're getting closer!
Johannes

[Johannes Schindelin]

Hi Jon,

On 2015-06-20 16:59, Jon wrote:

> 1) Why are there two ssl/certs trees? (e.g. - one is used by git-bash.exe
> and the other git-cmd.exe and cmd/git.exe?)

Please keep in mind that Git for Windows is a hybrid collection of pure Win32 executables and MSys2 executables (MSys2 is a stripped-down Cygwin providing a POSIX emulation layer on top of the Win32 API[*1*]). They are separated into the `/usr/` and the `/mingw64/` directories, respectively (`/mingw32/` for 32-bit). An example for a pure Win32 executable is `git.exe` while Perl and Bash are MSys2 executables. In general, we avoid MSys2 as much as possible: while it provides a nice POSIX emulation layer, it comes at a noticable performance penalty.

So whenever we can get away with using OpenSSL compiled as pure Win32 library, we do so. Cloning via HTTPS falls into that category.

When it comes to `git-svn` -- something that is needed by many users, still, and indeed the motivation for the most prolific contributor helping me with Git for Windows 2.x -- it is not that easy, though: `git-svn` is a Perl script, our Perl is an MSys2 program and therefore uses OpenSSL compiled as MSys2 library.

That is the reason why we have separate ssl/ directory structures. One for MinGW (i.e. pure Win32) programs and one for MSys2 ones.

> 2) Why are INSTALL_DIR/usr/ssl/certs/ca-bundle.crt and
> INSTALL_DIR/mingw64/ssl/certs/ca-bundle.crt different?

We simply use the packages provided by MSys2. The MinGW/MSys2 ca-certificates packages are sometimes out of sync, and that is what you are seeing here.

Now, theoretically it would be possible to reconcile the different ca-certificates packages into a single one. The correct way to go about this would be by contributing to the MSys2 project: that way, not only Git for Windows but really all MSys2-based projects benefit from it.

Ciao,
Johannes

Footnote *1*: https://msys2.github.io/

[Ties]

Hi Johannes,

Do you have an ETA on the final release? 

Regards,

Ties

ps I just found out about these release candidates, and I was already wondering for a while why we didn't had git 2.x on Windows. I'm going to install the RC, and test during day to day usage ;)

[Johannes Schindelin]

On 2015-06-26 13:06, Ties wrote:

> Do you have an ETA on the final release?

No, sorry, no ETA yet.

[Johannes Schindelin]

Hi all,

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

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

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

The most important changes are the update to Git 2.4.5 and a fix for the crash when running Git Bash with a legacy `TERM` setting (this should help 3rd party software to upgrade to Git for Windows 2.x).

Please find the release notes here:

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

Another step,
Johannes

[Johannes Schindelin]

Hi Stefan,

On 2015-06-29 11:07, Stefan Näwe wrote:

> Am 29.06.2015 um 10:30 schrieb Johannes Schindelin:

>> I just uploaded the 4th release candidate for the upcoming Git for
>> Windows 2.x release. Please find the download link here:
>>
>> https://git-for-windows.github.io/#download
>>
>> The most important changes are the update to Git 2.4.5 and a fix for the crash when running Git Bash
>> with a legacy `TERM` setting (this should help 3rd party software to upgrade to Git for Windows 2.x).
>

> Thanks.
> It seems that this link:
>
> https://github.com/git-for-windows/git/releases/latest
>
> doesn't point to the latest release.
>
> Might be because the tags have the same date ?

Wooops. Sorry for being so slow (been interviewing today). It should be correct now, can you verify, please?

Thanks,
Dscho

[Johannes Schindelin]

Hi Konstantin,

On 2015-06-29 17:54, Konstantin Khomoutov wrote:

> I've finally took time to switch from my old "msys1" release to this
> RC4, and immediately got hit by the fact Git is now speaking to me in
> Russian, which is not what I want (previously this behaviour was only
> exhibited by `git gui` and `gitk`).
>
> Should I make Git see LC_MESSAGES=en (or other thing like LANG) in the
> environment or is there some Git-local method to affect this behaviour?
> I tried to grep the release notes using relevant keywords but was left
> empty-handed.

Personally, I would use LC_ALL=C. Maybe that's good for you, too?

I guess this would also make for a fine opportunity to add an option to the installer to switch the localization off?

Ciao,
Johannes

[Thomas Braun]

Am 30.06.2015 um 19:15 schrieb Konstantin Khomoutov:

> On Mon, 29 Jun 2015 18:19:09 +0200
> Johannes Schindelin <johannes....@gmx.de> wrote:
>
>>> I've finally took time to switch from my old "msys1" release to this
>>> RC4, and immediately got hit by the fact Git is now speaking to me
>>> in Russian, which is not what I want (previously this behaviour was
>>> only exhibited by `git gui` and `gitk`).
>>>
>>> Should I make Git see LC_MESSAGES=en (or other thing like LANG) in
>>> the environment or is there some Git-local method to affect this
>>> behaviour? I tried to grep the release notes using relevant
>>> keywords but was left empty-handed.
>>
>> Personally, I would use LC_ALL=C. Maybe that's good for you, too?
>

> After reading [1], I've ended up installing LANG=C into my user's
> environment variables -- so far so good, thanks for the tip!

Just for the record.
I created the file lang.sh with contents
export LC_ALL=C
in
/etc/profile.d
which also fixes the problem. And also survives new versions of git.

[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

[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:

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