{"thread":{"id":"46519","subject":"[ANNOUNCE] Git for Windows 2.14.0","startedAt":"2017-08-05T23:00:23Z","lastAt":"2017-08-07T19:35:34Z","messageCount":8,"participants":["Johannes Schindelin","Johannes Sixt","Lars Schneider","Konstantin Khomoutov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325648","messageId":"20170805230001.3232-1-johannes.schindelin@gmx.de","threadId":"46519","inReplyTo":null,"subject":"[ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-05T23:00:01Z","receivedAt":"2017-08-05T23:00:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Dear Git users,\n\nIt is my pleasure to announce that Git for Windows 2.14.0 is available from:\n\n\thttps://git-for-windows.github.io/\n\nChanges since Git for Windows v2.13.3 (July 13th 2017)\n\nNew Features\n\n  * Comes with Git v2.14.0.\n  * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/\n    git-for-windows/busybox-w32/commit/9480dca7c].\n  * Comes with Git Credential Manager v1.12.0.\n  * It is now possible to switch between Secure Channel and OpenSSL for\n    Git's HTTPS transport by setting the http.sslBackend config\n    variable to \"openssl\" or \"schannel\"; This is now also the method\n    used by the installer (rather than copying libcurl-4.dll files\n    around).\n  * The experimental option --show-ignored-directory was added to git\n    status to show only the name of ignored directories when the option\n    --untracked=all is used.\n  * Git for Windows releases now also include an experimental\n    BusyBox-based MinGit.\n\nBug Fixes\n\n  * Repository-local aliases are now resolved again in worktrees.\n  * CamelCased aliases were broken in v2.13.3; This has been fixed\n    again.\n  * The 32-bit Git binaries are now built against the same dependencies\n    that are shipped with Git for Windows.\n\nFilename | SHA-256\n-------- | -------\nGit-2.14.0-64-bit.exe | 89799b4474bb62b2a266ed52fbe2f1e5d78598af61a7ef62c1ef94e2ac8de863\nGit-2.14.0-32-bit.exe | 74e5d76e6297fe1243d9a3e015b659bba032eecc1e538735b47e48325428e156\nPortableGit-2.14.0-64-bit.7z.exe | 7188ac81c9c48c8219355a0dae68461f99bab1976e9a5ab81b10bd994a83334e\nPortableGit-2.14.0-32-bit.7z.exe | 02e5d5f1bf611b6e0049743d4adf5ea7f4fb060e29809068cbba3b410632e01d\nMinGit-2.14.0-64-bit.zip | 56fab49a484bec42b733b2ed6335803fd2c9aa2a4cc24ab99863f543b764f507\nMinGit-2.14.0-32-bit.zip | a886cbe1d2c9cb5e1aa3e4ea92ab34878e101de3a3e2bed7f25059d376ec4eaa\nMinGit-2.14.0-busybox-64-bit.zip | 6102ac14721b79d5f950924cd6938b9d57d8cabd6b29e5209074c98b9ff1698f\nMinGit-2.14.0-busybox-32-bit.zip | 28fb513ad3891fb5d8f751370adf0e63b7c0d1f7b400260e07957b9d32767330\nGit-2.14.0-64-bit.tar.bz2 | 5a25702165218491fd6fc13e19016ecf0a7b703554194d14e817295c93b80be2\nGit-2.14.0-32-bit.tar.bz2 | 64baf1e284ecbbab38bc287747c6b4d76c5ef70f48def03044b440d24188a919\n\nCiao,\nJohannes\n"},{"id":"325653","messageId":"c532df98-b020-810a-c378-04c7dd5b0fa7@kdbg.org","threadId":"46519","inReplyTo":"20170805230001.3232-1-johannes.schindelin@gmx.de","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-08-06T08:34:33Z","receivedAt":"2017-08-06T08:34:41Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:\n> Dear Git users,\n> \n> It is my pleasure to announce that Git for Windows 2.14.0 is available from:\n> \n> \thttps://git-for-windows.github.io/\n> \n> Changes since Git for Windows v2.13.3 (July 13th 2017)\n\nThank you so much! One question, though:\n\n> New Features\n>...\n>    * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/\n>      git-for-windows/busybox-w32/commit/9480dca7c].\n\nWhat is the implication of this addition? I guess it is not just for the \nfun of it. Does it mean that all POSIX command line tools invoked by Git \nincluding a POSIX shell are now routed through busybox instead of the \nMSYS2 variant?\n\n-- Hannes\n"},{"id":"325654","messageId":"978038E7-74E8-4F9F-A3B9-0BAD82C80FFE@gmail.com","threadId":"46519","inReplyTo":"20170805230001.3232-1-johannes.schindelin@gmx.de","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-06T11:16:46Z","receivedAt":"2017-08-06T11:16:51Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 06 Aug 2017, at 01:00, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:\n> \n> Dear Git users,\n> \n> It is my pleasure to announce that Git for Windows 2.14.0 is available from:\n\nThank you :-)\n\n\n>  * It is now possible to switch between Secure Channel and OpenSSL for\n>    Git's HTTPS transport by setting the http.sslBackend config\n>    variable to \"openssl\" or \"schannel\"; This is now also the method\n>    used by the installer (rather than copying libcurl-4.dll files\n>    around).\n\nDoes anyone have a pros/cons list for this option? AFAIK OpenSSL is still\nthe default in the GfW installer and I wonder why. My gut feeling would be to \ngo with the SSL implementation shipped with the OS. However, I don't have enough \nknowledge of either implementation to make an assessment.\n\nOn macOS Git uses the Apple Security Framework instead of OpenSSL by default.\n\n- Lars\n\n"},{"id":"325669","messageId":"20170807082105.fwbv7d7hotsqeddx@tigra","threadId":"46519","inReplyTo":"978038E7-74E8-4F9F-A3B9-0BAD82C80FFE@gmail.com","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2017-08-07T08:21:05Z","receivedAt":"2017-08-07T08:21:24Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:\n\n[...]\n> >  * It is now possible to switch between Secure Channel and OpenSSL for\n> >    Git's HTTPS transport by setting the http.sslBackend config\n> >    variable to \"openssl\" or \"schannel\"; This is now also the method\n> >    used by the installer (rather than copying libcurl-4.dll files\n> >    around).\n> \n> Does anyone have a pros/cons list for this option? AFAIK OpenSSL is still\n> the default in the GfW installer and I wonder why. My gut feeling would be to \n> go with the SSL implementation shipped with the OS. However, I don't have enough \n> knowledge of either implementation to make an assessment.\n\nOne fact which immediately comes to mind is that both frameworks use\ndifferent sets of certificates (schannel uses the system's one, and\nOpenSSL uses what gets shipped with it).  Another fact is that they\nmight have different sets or protocols implemented and/or enabled by\ndefault.  Hence switching schannel on for people who used OpenSSL might\nbreak things for them.\n\n"},{"id":"325670","messageId":"alpine.DEB.2.21.1.1708071103220.4271@virtualbox","threadId":"46519","inReplyTo":"20170807082105.fwbv7d7hotsqeddx@tigra","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-07T09:20:14Z","receivedAt":"2017-08-07T09:20:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Lars & Konst,\n\nOn Mon, 7 Aug 2017, Konstantin Khomoutov wrote:\n\n> On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:\n> \n> [...]\n> > >  * It is now possible to switch between Secure Channel and OpenSSL for\n> > >    Git's HTTPS transport by setting the http.sslBackend config\n> > >    variable to \"openssl\" or \"schannel\"; This is now also the method\n> > >    used by the installer (rather than copying libcurl-4.dll files\n> > >    around).\n> > \n> > Does anyone have a pros/cons list for this option?\n\nThere is no exhaustive list of pros/cons as of time of writing. Off the\ntop of my head:\n\nOpenSSL pros:\n- well-tested\n- been the only option for Git for Windows in almost a decade\n\nOpenSSL cons:\n- does not integrate with the Windows Certificate Store\n\nSecure Channel pros:\n- well-tested\n- is an integral part of the Windows Operating System\n- supports the Windows Certificate Store\n\nSecure Channel cons:\n- has not been used by many Git for Windows users yet (so may have some\n  surprising issues?)\n- does not support OpenSSL's way of adding custom certificates via\n  ca-bundle.crt\n\nThe big deal with the Windows Certificate Store? It can be administered\nenterprise-wide via regular Windows administration tools. That makes a\nhuge difference when working with an internal server that has a custom SSL\ncertificate.\n\nPlease note that I, personally, have used Git for Windows almost\nexclusively via Secure Channel since late January this year. I have not\nhad *any* trouble. But then, I do not use servers with custom SSL\ncertificates at the moment.\n\n> > AFAIK OpenSSL is still the default in the GfW installer and I wonder\n> > why.\n\nOnly one reason: the law of least surprise. Some users went to certain\nlengths when working with custom SSL certificates, building elaborate\nupgrade scenarios that modify the ca-bundle.crt file (and of course none\nof those efforts try to help any other user having the same problem).\n\n> > My gut feeling would be to go with the SSL implementation shipped with\n> > the OS. However, I don't have enough knowledge of either\n> > implementation to make an assessment.\n\nThe reason I worked on cURL to allow choosing the SSL backend at runtime\nrather than build time is so that you can test this easier.\n\nPersonally, I think that Secure Channel is the better option, for the same\nreason you mentioned: it is integrated with Windows. So if you configure\nproxies via regular Windows settings, Secure Channel will definitely\nhandle it as expected. If you trust individual custom certificates via\nregular Windows mechanisms, Secure Channel will pick that up (IIUC).\n\nTherefore I would expect Secure Channel to provide a far superior user\nexperience to OpenSSL.\n\nAs a consequence, my plan is to switch the default from OpenSSL to Secure\nChannel when I feel that enough users have tested that backend and are as\nsatisfied with it as I am. This will of course *not* affect users who\nupgrade, as the Git for Windows installer remembers previous settings and\nreapplies them on upgrades.\n\n> One fact which immediately comes to mind is that both frameworks use\n> different sets of certificates (schannel uses the system's one, and\n> OpenSSL uses what gets shipped with it).  Another fact is that they\n> might have different sets or protocols implemented and/or enabled by\n> default.  Hence switching schannel on for people who used OpenSSL might\n> break things for them.\n\nIndeed. OTOH Secure Channel should be a safe default.\n\nCiao,\nDscho\n"},{"id":"325671","messageId":"alpine.DEB.2.21.1.1708071147430.4271@virtualbox","threadId":"46519","inReplyTo":"c532df98-b020-810a-c378-04c7dd5b0fa7@kdbg.org","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-07T10:02:10Z","receivedAt":"2017-08-07T10:02:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Hannes,\n\nOn Sun, 6 Aug 2017, Johannes Sixt wrote:\n\n> Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:\n> > Dear Git users,\n> > \n> > It is my pleasure to announce that Git for Windows 2.14.0 is available from:\n> > \n> >  https://git-for-windows.github.io/\n> > \n> > Changes since Git for Windows v2.13.3 (July 13th 2017)\n> \n> Thank you so much! One question, though:\n> \n> >New Features\n> >...\n> >    * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/\n> >      git-for-windows/busybox-w32/commit/9480dca7c].\n> \n> What is the implication of this addition? I guess it is not just for the\n> fun of it. Does it mean that all POSIX command line tools invoked by Git\n> including a POSIX shell are now routed through busybox instead of the\n> MSYS2 variant?\n\nAs I wrote a little later:\n\n* Git for Windows releases now also include an experimental [BusyBox-based\n  MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).\n\nAnd as I described in that Wiki entry, no, Git for Windows does not make\nuse of BusyBox just yet. Only the experimental version of MinGit.\n\nIt would be *awesome*, of course, to benefit from using BusyBox: size,\nspeed, robustness (reducing the MSYS2 dependency). But we're just not\nthere yet. What needs to happen before that?\n\n- lots of testing. And I mean *lotsssss* of testing. BusyBox is by far\n  less tried and tested than Bash, and BusyBox-w32 is *even less* tried\n  and tested. And BusyBox-w32 *with my patches* is tried and tested only a\n  little, and only by me. Before I risk getting bug reports about a\n  BusyBox-based Git for Windows, I want to be a lot more certain that\n  it is basically solid.\n\n- BusyBox-w32' interactive functionality expects a Win32 Console. In Git\n  Bash, we only have MSYS2's pseudo terminal, no Win32 Console. If we ever\n  want to be able to execute Git's scripts via BusyBox-w32, it *needs* to\n  learn about MSYS2 ptys, at least to emulate isatty() accordingly (we\n  have code in Git for Windows itself to do that, of course, it's no witch\n  craft, but... yet another thing to do).\n\n- judging by the number of bugs on Git for Windows' bug tracker, there\n  *are* some users out there installing their own hooks and aliases, and a\n  really tiny fraction of those users seems to be really happy to have a\n  full suite of GNU utilities available. BusyBox, however, does not\n  support that full functionality. Therefore, switching to BusyBox would\n  possibly break those setups.\n\nMind you, I really want to get there. And I think we will be able to get\nthere. By inviting testing (the BusyBox-based MinGit is a very good start,\nfor example). By adding an experimental option to Git for Windows'\ninstaller to switch to BusyBox. By announcing in Git for Windows' release\nnotes that this will become the default at some stage (\"please test your\naliases and hooks!\").\n\nCiao,\nDscho\n"},{"id":"325703","messageId":"f92fcfeb-75b9-6ee2-0bc0-a42d1dc01ebd@kdbg.org","threadId":"46519","inReplyTo":"alpine.DEB.2.21.1.1708071147430.4271@virtualbox","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-08-07T17:31:57Z","receivedAt":"2017-08-07T17:32:09Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:\n> On Sun, 6 Aug 2017, Johannes Sixt wrote:\n>> Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:\n>>>     * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/\n>>>       git-for-windows/busybox-w32/commit/9480dca7c].\n>>\n>> What is the implication of this addition? I guess it is not just for the\n>> fun of it. Does it mean that all POSIX command line tools invoked by Git\n>> including a POSIX shell are now routed through busybox instead of the\n>> MSYS2 variant?\n> \n> As I wrote a little later:\n> \n> * Git for Windows releases now also include an experimental [BusyBox-based\n>    MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).\n\nThanks for the clue. It's an interesting concept. I would be interested \nin replacing my old MSYS environment by BusyBox. At best, it would be \njust a matter of replacing sh.exe.\n\n-- Hannes\n"},{"id":"325729","messageId":"alpine.DEB.2.21.1.1708072127480.4271@virtualbox","threadId":"46519","inReplyTo":"f92fcfeb-75b9-6ee2-0bc0-a42d1dc01ebd@kdbg.org","subject":"Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-07T19:35:23Z","receivedAt":"2017-08-07T19:35:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Hannes,\n\nOn Mon, 7 Aug 2017, Johannes Sixt wrote:\n\n> Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:\n> > On Sun, 6 Aug 2017, Johannes Sixt wrote:\n> > > Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:\n> > > >     * Comes with [BusyBox\n> > > >     v1.28.0pre.15857.9480dca7c](https://github.com/\n> > > >       git-for-windows/busybox-w32/commit/9480dca7c].\n> > >\n> > > What is the implication of this addition? I guess it is not just for the\n> > > fun of it. Does it mean that all POSIX command line tools invoked by Git\n> > > including a POSIX shell are now routed through busybox instead of the\n> > > MSYS2 variant?\n> > \n> > As I wrote a little later:\n> > \n> > * Git for Windows releases now also include an experimental [BusyBox-based\n> >    MinGit](https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit).\n> \n> Thanks for the clue. It's an interesting concept. I would be interested in\n> replacing my old MSYS environment by BusyBox. At best, it would be just a\n> matter of replacing sh.exe.\n\nOpenSSH and GPG are also required for Git for Windows to function well.\nYou may not need them, but others do. Also, you may be content with\nrunning the shell in your Windows Console, but most users use MinTTY (and\nwould have used rxvt if we ever had gotten that to work).\n\nGiven your circumstances, I would estimate that you could already use\na BusyBox-based system. You have been traditionally very comfortable with\nrunning your own setup, and putting it together yourself, so you could\ncherry-pick the bits and pieces.\n\nThe only exception may be `vi`. While BusyBox comes with a `vi` applet, I\ndisabled it because it does not work in MinTTY, and it also offers a far\ncry from the vim.exe functionality I am used to. So you may want to revert\nhttps://github.com/git-for-windows/busybox-w32/commit/4dccf1500f4 and\nrebuild BusyBox-w32 yourself.\n\nCiao,\nDscho\n"}]}