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

[Robert Dailey]

When adding self-signed certificates, I see two locations:

E:\Git\usr\ssl\certs\ca-bundle.crt

E:\Git\mingw64\ssl\certs\ca-bundle.crt

It seems the 2nd one is the one used by git commands. I have to access a git server over HTTPS that uses a self-signed certificate. What is the purpose of the 1st ca-bundle.crt file? It would be more ideal to add to the first one since it doesn't depend on architecture (the path changes for 32-bit installs).

Do you have a recommended process for this?

[Mamta Upadhyay]

Hi, can you tell me if this is different than the official git 1.9.5 windows installer? I can see some files generated in the official build like libneon-25.dll, msys-ssl dll etc which does not exist here

[Philip Oakley]

From: "Mamta Upadhyay" <mamta.u...@gmail.com>

> Hi, can you tell me if this is different than the official git 1.9.5
> windows installer? I can see some files generated in the official
> build like libneon-25.dll, msys-ssl dll etc which does not exist here
>

Yes, they are different.

Mysgit had become harder to maintain and was limiting the aspirations of
some of the developers, so...

The developers are now trying to create a fresh Git for Windows based on
Msys2, with some newer bells and whistles and some more Linux/Unix
compatibility aspects which is the new release candidate. It's at the
stage where it needs real users to excercise all the dark and awkward
corners, and feedback the issues onto Guthub.

--

Philip

[Qb]

Dear Johannes,
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\

Dir layout
\
\CustomFolder
\CustomFolder\files.....
\CustomFolder\CustomFolder\.git  <---- wrong additional level
 
so any other command doesn't work because it cannot find the .git folder.
If I move the CustomFolder\CustomFolder\.git to CustomFolder\.git everything works correctly.

Let me know if it's enough data,
Qb

[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

[QbProg]

Hello,

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

Qb

[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

[Mamta Upadhyay]

Thanks Philip. For some reason, I need to rebuild git 1.9.5 and I have downloaded msysgit. Once I build, how do I package the required files to create a git installer?

[Johannes Schindelin]

Hi,

On 2015-06-10 02:53, Mamta Upadhyay wrote:
> Thanks Philip. For some reason, I need to rebuild git 1.9.5 and I have
> downloaded msysgit. Once I build, how do I package the required files
> to
> create a git installer?

Please note that top-posting is considered a bit sloppy on this mailing
list, inviting less thorough answers than otherwise. You might want to
consider this in future responses.

As to your question: the answer is in
https://github.com/msysgit/msysgit/blob/master/share/WinGit/HowToRelease.txt,
linked from
https://github.com/msysgit/msysgit/wiki/InstallMSysGit#How_to_remake_the_installer

Ciao,
Johannes

[Mamta Upadhyay]

Thanks for your response Johannes and sorry about top-posting. I will take care of this in the future.

[Mamta Upadhyay]

I tried the links you sent, but looks like they are for creating msysgit installers. I want to create the git installer (just like https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/Git-1.9.5-preview20150319.exe)

Tried share/WinGit/release.sh but it keeps on giving me this error:

Error in C:\DOCUME~1\UPADHY~1\LOCALS~1\Temp\1\WinGit\install.iss: Could not
copy "C:\msysgit-1.9.5\share\InnoSetup\SETUP.E32" to "h:\Git-1.9.5-test.e32.tm
p".

Error 1816: Not enough quota is available to process this command.
Compile aborted.

On Wednesday, June 10, 2015 at 8:00:22 AM UTC-5, Johannes Schindelin wrote:

[Mamta Upadhyay]

Ok, I was able to resolve that issue by elevating the privileges. Sorry for the trouble and thanks again for your help!

[Robert Dailey]

On Wednesday, May 27, 2015 at 5:11:37 PM UTC-5, Johannes Schindelin wrote:

It's no longer clear exactly how to setup self-signed certificates in this new version of Git:

$ git fetch origin

fatal: unable to access 'https://mygitserver/myrepo.git/': SSL certificate problem: self signed certificate in certificate chain

No one on my team at $DAYJOB uses SSH, they all use HTTPS. Switching everyone to SSH certainly won't be an option either. So prior to asking everyone to upgrade, I'll need to be able to provide them instruction on how to properly setup our cert so that HTTPS works properly.

Ideally the solution will be done in such a way that when installing newer versions of Git for Windows, that the keys are not overwritten. Using the normal Git config approach won't work either since when you get the CA cert path to our key, it no longer knows about the other built-in certs, so fetches from github.com and the like will also fail.

Maybe there is an elegant or easy solution to this. But I just haven't found it yet.

 

[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

[Jon]

Fantastic!

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?)
2) Why are INSTALL_DIR/usr/ssl/certs/ca-bundle.crt and INSTALL_DIR/mingw64/ssl/certs/ca-bundle.crt different?


C:\Apps\git2>mingw64\bin\git.exe version
git version 2.4.4.windows.2

C:\Apps\git2>usr\bin\diff.exe --brief usr\ssl\certs\ca-bundle.crt mingw64\ssl\certs\ca-bundle.crt
Files usr\ssl\certs\ca-bundle.crt and mingw64\ssl\certs\ca-bundle.crt differ

[Johannes Schindelin]

Hi Jon,

On 2015-06-20 16:59, Jon wrote:
> On Saturday, June 20, 2015 at 10:16:09 AM UTC-4, Johannes Schindelin wrote:
>>
>> 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
>

> 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/

[Robert Dailey]

Let me add a question to this: how does one add new certs? If there are multiple files. I have an issue open for this but still no information. Thanks in advance.

Sorry for top post, replying on my phone.

[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

[Stefan Näwe]

Am 29.06.2015 um 10:30 schrieb 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).

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 ?

Thanks anyway!

Stefan
--
----------------------------------------------------------------
/dev/random says: Who needs comedians? Journalists are much more laughable!
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF

[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

[Stefan Näwe]

Yes.

https://github.com/git-for-windows/git/releases/latest
redirects to "Fourth release candidate of Git for Windows 2.x" now.

Thanks,
Stefan
--
----------------------------------------------------------------
/dev/random says: Documentation is the castor oil of programming.

[Konstantin Khomoutov]

On Mon, 29 Jun 2015 16:37:54 +0200
Johannes Schindelin <johannes....@gmx.de> wrote:

> >> 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 for making all this real, Johannes!

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.

[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

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

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

I dunno.
While this definitely would be useful for some folks (mostly
old-school, like we do) but the problem with this setting is that it's
not specific to Git and can result in unpredictable behaviour in other
parts of the system. Hence this option, if implemented, should somehow
be clearly marked as system-wide in the installer UI.

1. https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html

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