[ANNOUNCE] Git for Windows 2.14.0

[ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin]

Dear Git users,

It is my pleasure to announce that Git for Windows 2.14.0 is available from:

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

Changes since Git for Windows v2.13.3 (July 13th 2017)

New Features

  * Comes with Git v2.14.0.
  * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
    git-for-windows/busybox-w32/commit/9480dca7c].
  * Comes with Git Credential Manager v1.12.0.
  * It is now possible to switch between Secure Channel and OpenSSL for
    Git's HTTPS transport by setting the http.sslBackend config
    variable to "openssl" or "schannel"; This is now also the method
    used by the installer (rather than copying libcurl-4.dll files
    around).
  * The experimental option --show-ignored-directory was added to git
    status to show only the name of ignored directories when the option
    --untracked=all is used.
  * Git for Windows releases now also include an experimental
    BusyBox-based MinGit.

Bug Fixes

  * Repository-local aliases are now resolved again in worktrees.
  * CamelCased aliases were broken in v2.13.3; This has been fixed
    again.
  * The 32-bit Git binaries are now built against the same dependencies
    that are shipped with Git for Windows.

Filename | SHA-256
-------- | -------
Git-2.14.0-64-bit.exe | 89799b4474bb62b2a266ed52fbe2f1e5d78598af61a7ef62c1ef94e2ac8de863
Git-2.14.0-32-bit.exe | 74e5d76e6297fe1243d9a3e015b659bba032eecc1e538735b47e48325428e156
PortableGit-2.14.0-64-bit.7z.exe | 7188ac81c9c48c8219355a0dae68461f99bab1976e9a5ab81b10bd994a83334e
PortableGit-2.14.0-32-bit.7z.exe | 02e5d5f1bf611b6e0049743d4adf5ea7f4fb060e29809068cbba3b410632e01d
MinGit-2.14.0-64-bit.zip | 56fab49a484bec42b733b2ed6335803fd2c9aa2a4cc24ab99863f543b764f507
MinGit-2.14.0-32-bit.zip | a886cbe1d2c9cb5e1aa3e4ea92ab34878e101de3a3e2bed7f25059d376ec4eaa
MinGit-2.14.0-busybox-64-bit.zip | 6102ac14721b79d5f950924cd6938b9d57d8cabd6b29e5209074c98b9ff1698f
MinGit-2.14.0-busybox-32-bit.zip | 28fb513ad3891fb5d8f751370adf0e63b7c0d1f7b400260e07957b9d32767330
Git-2.14.0-64-bit.tar.bz2 | 5a25702165218491fd6fc13e19016ecf0a7b703554194d14e817295c93b80be2
Git-2.14.0-32-bit.tar.bz2 | 64baf1e284ecbbab38bc287747c6b4d76c5ef70f48def03044b440d24188a919

Ciao,
Johannes

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Sixt]

Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> Dear Git users,
> 
> It is my pleasure to announce that Git for Windows 2.14.0 is available from:
> 
> 	https://git-for-windows.github.io/
> 
> Changes since Git for Windows v2.13.3 (July 13th 2017)

Thank you so much! One question, though:

> New Features
>...
>    * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
>      git-for-windows/busybox-w32/commit/9480dca7c].

What is the implication of this addition? I guess it is not just for the 
fun of it. Does it mean that all POSIX command line tools invoked by Git 
including a POSIX shell are now routed through busybox instead of the 
MSYS2 variant?

-- Hannes

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Lars Schneider]

> On 06 Aug 2017, at 01:00, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
> 
> Dear Git users,
> 
> It is my pleasure to announce that Git for Windows 2.14.0 is available from:

Thank you :-)


>  * It is now possible to switch between Secure Channel and OpenSSL for
>    Git's HTTPS transport by setting the http.sslBackend config
>    variable to "openssl" or "schannel"; This is now also the method
>    used by the installer (rather than copying libcurl-4.dll files
>    around).

Does anyone have a pros/cons list for this option? AFAIK OpenSSL is still
the default in the GfW installer and I wonder why. My gut feeling would be to 
go with the SSL implementation shipped with the OS. However, I don't have enough 
knowledge of either implementation to make an assessment.

On macOS Git uses the Apple Security Framework instead of OpenSSL by default.

- Lars

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Konstantin Khomoutov]

On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:

[...]
> >  * It is now possible to switch between Secure Channel and OpenSSL for
> >    Git's HTTPS transport by setting the http.sslBackend config
> >    variable to "openssl" or "schannel"; This is now also the method
> >    used by the installer (rather than copying libcurl-4.dll files
> >    around).
> 
> Does anyone have a pros/cons list for this option? AFAIK OpenSSL is still
> the default in the GfW installer and I wonder why. My gut feeling would be to 
> go with the SSL implementation shipped with the OS. However, I don't have enough 
> knowledge of either implementation to make an assessment.

One fact which immediately comes to mind is that both frameworks use
different sets of certificates (schannel uses the system's one, and
OpenSSL uses what gets shipped with it).  Another fact is that they
might have different sets or protocols implemented and/or enabled by
default.  Hence switching schannel on for people who used OpenSSL might
break things for them.

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin]

Hi Lars & Konst,

On Mon, 7 Aug 2017, Konstantin Khomoutov wrote:

> On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:
> 
> [...]
> > >  * It is now possible to switch between Secure Channel and OpenSSL for
> > >    Git's HTTPS transport by setting the http.sslBackend config
> > >    variable to "openssl" or "schannel"; This is now also the method
> > >    used by the installer (rather than copying libcurl-4.dll files
> > >    around).
> > 
> > Does anyone have a pros/cons list for this option?

There is no exhaustive list of pros/cons as of time of writing. Off the
top of my head:

OpenSSL pros:
- well-tested
- been the only option for Git for Windows in almost a decade

OpenSSL cons:
- does not integrate with the Windows Certificate Store

Secure Channel pros:
- well-tested
- is an integral part of the Windows Operating System
- supports the Windows Certificate Store

Secure Channel cons:
- has not been used by many Git for Windows users yet (so may have some
  surprising issues?)
- does not support OpenSSL's way of adding custom certificates via
  ca-bundle.crt

The big deal with the Windows Certificate Store? It can be administered
enterprise-wide via regular Windows administration tools. That makes a
huge difference when working with an internal server that has a custom SSL
certificate.

Please note that I, personally, have used Git for Windows almost
exclusively via Secure Channel since late January this year. I have not
had *any* trouble. But then, I do not use servers with custom SSL
certificates at the moment.

> > AFAIK OpenSSL is still the default in the GfW installer and I wonder
> > why.

Only one reason: the law of least surprise. Some users went to certain
lengths when working with custom SSL certificates, building elaborate
upgrade scenarios that modify the ca-bundle.crt file (and of course none
of those efforts try to help any other user having the same problem).

> > My gut feeling would be to go with the SSL implementation shipped with
> > the OS. However, I don't have enough knowledge of either
> > implementation to make an assessment.

The reason I worked on cURL to allow choosing the SSL backend at runtime
rather than build time is so that you can test this easier.

Personally, I think that Secure Channel is the better option, for the same
reason you mentioned: it is integrated with Windows. So if you configure
proxies via regular Windows settings, Secure Channel will definitely
handle it as expected. If you trust individual custom certificates via
regular Windows mechanisms, Secure Channel will pick that up (IIUC).

Therefore I would expect Secure Channel to provide a far superior user
experience to OpenSSL.

As a consequence, my plan is to switch the default from OpenSSL to Secure
Channel when I feel that enough users have tested that backend and are as
satisfied with it as I am. This will of course *not* affect users who
upgrade, as the Git for Windows installer remembers previous settings and
reapplies them on upgrades.

> One fact which immediately comes to mind is that both frameworks use
> different sets of certificates (schannel uses the system's one, and
> OpenSSL uses what gets shipped with it).  Another fact is that they
> might have different sets or protocols implemented and/or enabled by
> default.  Hence switching schannel on for people who used OpenSSL might
> break things for them.

Indeed. OTOH Secure Channel should be a safe default.

Ciao,
Dscho

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin]

Hi Hannes,

On Sun, 6 Aug 2017, Johannes Sixt wrote:

> Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> > Dear Git users,
> > 
> > It is my pleasure to announce that Git for Windows 2.14.0 is available from:
> > 
> >  https://git-for-windows.github.io/
> > 
> > Changes since Git for Windows v2.13.3 (July 13th 2017)
> 
> Thank you so much! One question, though:
> 
> >New Features
> >...
> >    * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
> >      git-for-windows/busybox-w32/commit/9480dca7c].
> 
> What is the implication of this addition? I guess it is not just for the
> fun of it. Does it mean that all POSIX command line tools invoked by Git
> including a POSIX shell are now routed through busybox instead of the
> MSYS2 variant?

As I wrote a little later:

* Git for Windows releases now also include an experimental [BusyBox-based
  MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).

And as I described in that Wiki entry, no, Git for Windows does not make
use of BusyBox just yet. Only the experimental version of MinGit.

It would be *awesome*, of course, to benefit from using BusyBox: size,
speed, robustness (reducing the MSYS2 dependency). But we're just not
there yet. What needs to happen before that?

- lots of testing. And I mean *lotsssss* of testing. BusyBox is by far
  less tried and tested than Bash, and BusyBox-w32 is *even less* tried
  and tested. And BusyBox-w32 *with my patches* is tried and tested only a
  little, and only by me. Before I risk getting bug reports about a
  BusyBox-based Git for Windows, I want to be a lot more certain that
  it is basically solid.

- BusyBox-w32' interactive functionality expects a Win32 Console. In Git
  Bash, we only have MSYS2's pseudo terminal, no Win32 Console. If we ever
  want to be able to execute Git's scripts via BusyBox-w32, it *needs* to
  learn about MSYS2 ptys, at least to emulate isatty() accordingly (we
  have code in Git for Windows itself to do that, of course, it's no witch
  craft, but... yet another thing to do).

- judging by the number of bugs on Git for Windows' bug tracker, there
  *are* some users out there installing their own hooks and aliases, and a
  really tiny fraction of those users seems to be really happy to have a
  full suite of GNU utilities available. BusyBox, however, does not
  support that full functionality. Therefore, switching to BusyBox would
  possibly break those setups.

Mind you, I really want to get there. And I think we will be able to get
there. By inviting testing (the BusyBox-based MinGit is a very good start,
for example). By adding an experimental option to Git for Windows'
installer to switch to BusyBox. By announcing in Git for Windows' release
notes that this will become the default at some stage ("please test your
aliases and hooks!").

Ciao,
Dscho

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Sixt]

Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
> On Sun, 6 Aug 2017, Johannes Sixt wrote:
>> Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
>>>     * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
>>>       git-for-windows/busybox-w32/commit/9480dca7c].
>>
>> What is the implication of this addition? I guess it is not just for the
>> fun of it. Does it mean that all POSIX command line tools invoked by Git
>> including a POSIX shell are now routed through busybox instead of the
>> MSYS2 variant?
> 
> As I wrote a little later:
> 
> * Git for Windows releases now also include an experimental [BusyBox-based
>    MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).

Thanks for the clue. It's an interesting concept. I would be interested 
in replacing my old MSYS environment by BusyBox. At best, it would be 
just a matter of replacing sh.exe.

-- Hannes

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin]

Hi Hannes,

On Mon, 7 Aug 2017, Johannes Sixt wrote:

> Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
> > On Sun, 6 Aug 2017, Johannes Sixt wrote:
> > > Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> > > >     * Comes with [BusyBox
> > > >     v1.28.0pre.15857.9480dca7c](https://github.com/
> > > >       git-for-windows/busybox-w32/commit/9480dca7c].
> > >
> > > What is the implication of this addition? I guess it is not just for the
> > > fun of it. Does it mean that all POSIX command line tools invoked by Git
> > > including a POSIX shell are now routed through busybox instead of the
> > > MSYS2 variant?
> > 
> > As I wrote a little later:
> > 
> > * Git for Windows releases now also include an experimental [BusyBox-based
> >    MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).
> 
> Thanks for the clue. It's an interesting concept. I would be interested in
> replacing my old MSYS environment by BusyBox. At best, it would be just a
> matter of replacing sh.exe.

OpenSSH and GPG are also required for Git for Windows to function well.
You may not need them, but others do. Also, you may be content with
running the shell in your Windows Console, but most users use MinTTY (and
would have used rxvt if we ever had gotten that to work).

Given your circumstances, I would estimate that you could already use
a BusyBox-based system. You have been traditionally very comfortable with
running your own setup, and putting it together yourself, so you could
cherry-pick the bits and pieces.

The only exception may be `vi`. While BusyBox comes with a `vi` applet, I
disabled it because it does not work in MinTTY, and it also offers a far
cry from the vim.exe functionality I am used to. So you may want to revert
https://github.com/git-for-windows/busybox-w32/commit/4dccf1500f4 and
rebuild BusyBox-w32 yourself.

Ciao,
Dscho