[ANNOUNCE] Git for Windows 2.10.1

[Johannes Schindelin]

Dear Git users,

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

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

Changes since Git for Windows v2.10.0 (September 3rd 2016)

New Features

• Comes with Git v2.10.1.
• Comes with Git Credential Manager v1.7.0.
• Comes with Git Flow v1.10.0.
• We now produce nice diffs for .docm and .dotm files, just as we did
for .docx files already.

Bug Fixes

• The icon in the Explorer integration ("Git Bash Here"), which was
lost by mistake in v2.10.0, is back.
• Fixed a crash when calling git diff -G<regex> on new-born files
without configured user diff drivers.
• Interactive GPG signing of commits and tags was fixed.
• Calling Git with --date=format:<invalid-format> no longer results
in an out-of-memory but reports the problem and aborts instead.
• Git Bash now opens properly even for Azure AD accounts.
• Git GUI respects the commit.gpgsign setting again.
• Upgrades the bundled OpenSSL to v1.0.2j.

Filename | SHA-256
-------- | -------
Git-2.10.1-64-bit.exe | 0fcb5a3d5795d5bfa1c0d35d1cada37f25b5e62c776a7099f27cfebc31362d95
Git-2.10.1-32-bit.exe | 66e0748cb0eb0b63506f38fb8bf1abb5c361ce647af86cb0f754bc5b6a17775b
PortableGit-2.10.1-64-bit.7z.exe | aa0634e026c70fe8b50207b8b125a18f45e259eac32cea246e068577a6546718
PortableGit-2.10.1-32-bit.7z.exe | 3ca6f426e3b2e6675a11b680f719c23affa7e4dc060e315375c6a262ed2658a5
MinGit-2.10.1-64-bit.zip | a7268f4ab447e62940347d52fe01321403cfa3e9e94b8e5cac4d6ded28962d64
MinGit-2.10.1-32-bit.zip | bcdeb7c00771f0e8e96689f704d158e8dcf67fdb4178f1ea3f388e877398a2c7
Git-2.10.1-64-bit.tar.bz2 | c0a541a60be3ea6264a269b90689b15da3e27811218e8c214359ec44593faa8e
Git-2.10.1-32-bit.tar.bz2 | 3c77a702911512708126e83673c5906af78807bcb9daad5223b0ab04ea81f4ea

Ciao,
Johannes

[mvs]

Upon upgrading to 2.10.1 on WinXP machine from 2.10 during install I get error message

Procedure entry point CancelSynchronousIo could not be located in the dynamic link library KERNEL32.dll 

for

rebase.exe

dash.exe

bash.exe

Maurizio

[Johannes Schindelin]

Hi Maurizio,

On Wed, 5 Oct 2016, mvs wrote:

> Upon upgrading to 2.10.1 on WinXP machine from 2.10 during install I get
> error message
>
> Procedure entry point CancelSynchronousIo could not be located in the
> dynamic link library KERNEL32.dll
>
> for
>
> rebase.exe
> dash.exe
> bash.exe

This issue has been reported here:

https://github.com/git-for-windows/git/issues/906

The reason is that we had to update the MSYS2 runtime (in order to fix Git
for Windows in conjunction with Azure Active Directory accounts) and this
update also dropped support for Windows versions that are past their
end-of-life.

See also
https://github.com/git-for-windows/git/wiki/FAQ#which-versions-of-windows-are-supported

Ciao,
Johannes

P.S.: As I mentioned in issue #906, if any contributor feels strongly
enough about XP and 2k3 support to put in the effort to make MSYS2's
runtime work on said platforms again, I will do my part to maintain that
functionality, of course.

[mvs]

OK,  I understand. I downgraded to git 2.10 and in any case I am going to change soon my PC to Win10. You can't live forever on XP...

Thanks

Maurizio

[asmwarrior]

I have the same exact issue in Windows XP as Maurizio reported days before.
We have many people still using Windows XP as working machine, so for me, I have to downgrade to 2.10 version.
For me, I still suggest git for windows could still support XP, thanks.

Asmwarrior

[Konstantin Khomoutov]

Please understand that GfW has little to do with it because it uses
MSYS2, and it's that project which started shipping msys-2.0.dll wihch
now fails to import that specific symbol from kernel32.dll.

What's worse, MSYS2 itself syncs with the Cygwin code base, so it all
started there -- in the new Cygwin release.

I, too, am affected by this change as I have a Windows XP around (and
will continue to do this in a foreseeable future as I have to support
some obscure in-house application written in Delphi 7, and there's no
financial incentive to re-write it in something more up-to-date), but I
can understand folks both behind GfW and MSYS2 and Cygwin projects:
there's only that much amount of effort you can put into supporting old
crap. So if someone (or -- better -- someone's employer) can put the
necessary effort into supporting MSYS2 core which will continue to work
on WinXP that would be great but expecting other people doing this is
not really appropriate: they have lots of other stuff to do.

[Johannes Schindelin]

Hi,

On Fri, 7 Oct 2016, Konstantin Khomoutov wrote:

> On Fri, 7 Oct 2016 00:59:13 -0700 (PDT)
> asmwarrior <asmwa...@gmail.com> wrote:
>
> > I have the same exact issue in Windows XP as Maurizio reported days
> > before. We have many people still using Windows XP as working
> > machine, so for me, I have to downgrade to 2.10 version.
> > For me, I still suggest git for windows could still support XP,
> > thanks.

Please note that this sounds quite a bit demanding. Maybe you really do
not understand just how much work you are asking for, without any
indication what you would provide in return.

> So if someone (or -- better -- someone's employer) can put the necessary
> effort into supporting MSYS2 core which will continue to work on WinXP
> that would be great but expecting other people doing this is not really
> appropriate: they have lots of other stuff to do.

Let me be quite clear: I have no objection whatsoever to do my share of
maintaining XP/2003 support. But I do expect that developers with access
to those platforms do their part, too.

A viable solution would be for someone with the need for XP support, and
who is competent enough to work with the Cygwin runtime's source code, to
step up and figure out what changes broke the support and to revert them.
I would then review those changes and release a new MSYS2 runtime as soon
as the changes are good. This someone would be my go-to person to test XP
support whenever we need to synchronize the MSYS2 runtime with a new
version from upstream. And if things break, I would trust that developer
to unbreak them, possibly with my help.

In short: this will not come for free. It will require substantially more
than asking others to do the job.

(And to be clear: Konstantin, this remark is not directed at you. You
contribute so much by being active in the community, answering tons and
tons of questions, being helpful and all. Thank you!)

Ciao,
Johannes

[elizar...@gmail.com]

I looked into the new msys-2.0.dll that comes with Git for Windows 2.10.1.  Unfortunately, CancelSynchronousIo is not the only API that is missing on XP.  If it were the only API, then working around it would have been easy: call it through a function pointer whose value is assigned by GetProcAddress at run time, and if the latter return NULL, treat that as if CancelSynchronousIo failed.  The Cygwin sources call this function in a single place, so such a change would be a no-brainer.

However, there are more missing APIs.  Here's the list of APIs that are missing on my XP SP3 machine:

• From NTDLL.DLL:
  
• NtCommitTransaction
• NtCreateTransaction
• NtRollbackTransaction
• RtlGetCurrentTransaction
• RtlSetCurrentTransaction
• From KERNEL32.DLL:
• CancelSynchronousIo
• CreateSymbolicLinkW
• GetNamedPipeClientProcessId
• GetThreadId
• IdnToAscii
• IdnToUnicode
• LocaleNameToLCID
• SetThreadStackGuarantee

The "*Transaction" part is used for implementing atomic file I/O, in unlink() and rename().
GetNamedPipeClientProcessId is used in termios support.
The "Idn*" APIs are used for IDNA.
Etc. etc. -- each one of these is used in a small number of places, but figuring out what to do about each one is not always simple.

[elizar...@gmail.com]

Is it possible to unpack just the MinGW parts of Git 2.10.1 on top of a 2.10.0 installation, keeping the MSYS2 parts (the ones below bin/ and usr/bin/ directories)?  If the problem is only for MSYS2 rruntime and related programs, then MinGW compiled parts of Git, which is the Git core, should not be affected, right?

While at that, can someone please explain what is MinGit-X.Y.Z-32-bit.zip, or point to a documentation which describes the various files distributed from the Git releases page?  TIA.

[elizar...@gmail.com]

If the MSYS2 runtime upgrade was required for Azure support, then how about offering a separate 32-bit Git installer with the older MSYS2 runtime, for the XP systems?  I assume those systems don't need the Azure support (do they?), and even if they do, it would be a fair tradeoff for users of such systems to decide what is more important for them: a newer Git or Azure support.

Thanks.

[elizar...@gmail.com]

Could someone please answer the questions below, regarding the possibility of having an installer that targets XP, where the MinGW programs are updated, but the MSYS2 runtime is the older one that supports XP?

Also, where can I find some documentation regarding the various archives offered with every release?  There's the .exe installer, a .tar.bz2 archive with binaries, and a MinGit archive.  What are the differences between these 3 and when/how should each one be used?

Thanks in advance.

[Dakota Hawkins]

On Fri, Oct 14, 2016 at 5:48 AM, <elizar...@gmail.com> wrote:
> Could someone please answer the questions below, regarding the possibility
> of having an installer that targets XP, where the MinGW programs are
> updated, but the MSYS2 runtime is the older one that supports XP?

I'd say it's an unreasonable request.

How come you need a new git version but are OK with an old MSYS2
runtime? If this were going to get done at all, why would GfW
incorporate a hack do it instead of MSYS2 or Cygwin doing it?
Presumably you get all kinds of nice things GfW might want to depend
on with these updated runtimes, I'd rather not see GfW held back in
some way because it's bound to supporting an obsolete version as well
as an up-to-date version.

XP had a good run, but it's dead. If MS hasn't been supporting
it/patching it for more than two years, I don't see why anybody should
expect XP support from other developers -- especially developers that
don't make you pay for their work :-)

Dakota

[elizar...@gmail.com]

Thank you for replying.

The old MSYS2 runtime is OK for XP users because AFAIU the changes in the newer MSYS2 target features available only on newer Windows versions.

I don't expect the MSYS2 project to be amenable to requests for supporting XP, because MSYS2 is primarily a tool for building MinGW packages, not for using them.  It is IMO reasonable to tell people who build packages to use newer Windows versions.  By contrast, GfW uses MSYS2 as part of the application, so this limitation affects systems where applications are run, not just developed.

I don't think this will hold GfW back, because I was asking for an additional, separate installer, which would be used on XP and older systems, while newer systems can use the installer that comes with a newer MSYS2 runtime.  IOW, all it should take the GfW developers is to produce an additional installer using a frozen MSYS2 runtime that never changes.  I hope this is not a significant effort.

And no, XP is not dead.  There are many installations in the industry, as target systems for many products.  That MS stopped supporting them doesn't mean those systems are going to go away any time soon.

But I don't want to argue about the future of XP, or lack thereof.  I just hope it will be possible to still allow XP users to have newer GfW without incurring any significant additional efforts on the GfW developers.

Thanks

[Johannes Schindelin]

Hi,

On Fri, 14 Oct 2016, elizar...@gmail.com wrote:

> The old MSYS2 runtime is OK for XP users because AFAIU the changes in
> the newer MSYS2 target features available only on newer Windows
> versions.

You should not make those claims without having reviewed the changes in
newer MSYS2 runtimes.

The changes comprise new features, of course, but also bug fixes. And new
functions.

> I don't expect the MSYS2 project to be amenable to requests for
> supporting XP, because MSYS2 is primarily a tool for building MinGW
> packages, not for using them.

First of all, MSYS2 is *not* primarily a tools for building MinGW
packages. It can serve as such, but its primary mission is to provide a
package management system ("Pacman") and many packages with up-to-date
versions of Open Source.

And second, the MSYS2 project will most likely be amenable to
contributions that reinstate XP. Contributions, as in: patches, Pull
Requests, and some such. It has to be said again: talk is cheap.
Requesting others to work takes, what, 5 minutes? Actually doing the
bidding would take weeks. That is what you are asking others to do for
you.

> I don't think this will hold GfW back, because I was asking for an
> additional, separate installer, which would be used on XP and older
> systems, while newer systems can use the installer that comes with a
> newer MSYS2 runtime.

Yes, you were asking me to put in more work, spend more time maintaining
separate installers in addition to the ones I already maintain, for your
pleasure.

Such a request does not sound reasonable to me, but like a foul deal, with
me, personally, on the short end.

> IOW, all it should take the GfW developers is to produce an additional
> installer using a frozen MSYS2 runtime that never changes. I hope this
> is not a significant effort.

You hope? Why don't you give it a try yourself before trying to assign
work to others?

And no, the MSYS2 runtime cannot be frozen, as some of the components we
include in Git for Windows link to it (e.g. MinTTY and OpenSSH) and those
components may well require newer versions of the MSYS2 runtime (you can
verify this for yourself by trying to launch mintty.exe from, say,
v2.10.1 against msys-2.0.dll from, say, 2.7.0).

> And no, XP is not dead.

It is past its end of life. This is what some people equate to "being
dead".

It is highly recommended to upgrade to newer Windows versions, as newly
discovered security issues will not be patched.

> There are many installations in the industry, as target systems for many
> products. That MS stopped supporting them doesn't mean those systems
> are going to go away any time soon.

That may be so, but the official statement is that XP is past its official
support, which means that you have to live with limitations if you keep
using it.

One such limitation is that you do not get to ask others to reinstate XP
support in a software you would like to use, but that you have to put in
effort or money to get it done.

> But I don't want to argue about the future of XP, or lack thereof.

Too late. You already did.

> I just hope it will be possible to still allow XP users to have newer
> GfW without incurring any significant additional efforts on the GfW
> developers.

As I said, that hope is misplaced.

Unless, that is, you choose to join the rank of the Git for Windows
developers yourself and provide your fair share of what is a pretty great
Open Source project.

Ciao,
Johannes

[elizar...@gmail.com]

Look, I don't really understand the reason for the hostility.  I made a request; if your decision is to reject it, you are free to do that, but why do you need to represent my request as something unreasonable, let alone shameful?  It's simply unfair.

A single person can only do so much with their free time, developing Free Software packages as a volunteer.  I participate in development of some of them (Emacs, Guile, Wget, GNU Make, GDB, Gawk, and Texinfo, to name just a few).  You may be even using some of them in your day-to-day work on GfW.  I also maintain a site, ezwinports, where MinGW binaries of several useful packages are made available regularly for others to use.  This is my "fair share" of the work, some of which even ends up in GfW.

But there's always some point beyond which each one of us cannot solve problems on our own, for lack of time or knowledge, or both, and that is when we ask developers of other projects to help.  That is what I did.  It is unreasonable to expect everyone to solve their problems with every package they use by themselves.  So I don't really see why I deserve the kind of attitude you give me.  "For your pleasure"?  "Talk is cheap"?  Is this a proper way to treat your fellow volunteer who, like you, works on some of "pretty great Open Software packages", thus indirectly helping you with yours?

[Konstantin Khomoutov]

On Fri, 14 Oct 2016 11:20:16 -0700 (PDT)
elizar...@gmail.com wrote:

> Look, I don't really understand the reason for the hostility. I made
> a request; if your decision is to reject it, you are free to do that,
> but why do you need to represent my request as something
> unreasonable, let alone shameful? It's simply unfair.

[...]

> So I don't really see why I deserve the kind of attitude you give
> me. "For your pleasure"? "Talk is cheap"? Is this a proper way to
> treat your fellow volunteer who, like you, works on some of "pretty
> great Open Software packages", thus indirectly helping you with yours?

Well put, I admit.

Unfortunately, the shots were fired.
On the other hand, the opinions on the both sides of the fence were
formulated, are hence known, and are unlikely to change -- I presume.
I would also say both sides have their valid reasons for their
respective opinions.

So I propose to put an end to this discussion before it got derailed
even more off the technical track.

It got archived both here and in the GfW bugtracker so whoever will
stumble on the same problem will be able to find it and act
appropriately (or inappropriately) ;-)

[Johannes Schindelin]

Hi,

On Fri, 14 Oct 2016, elizar...@gmail.com wrote:

> Look, I don't really understand the reason for the hostility.

No hostility. I did get annnoyed a little that I had to repeat myself a
couple of times (I'd much rather work on coding and bug fixing than having
to explain the same thing twice), I hope you will excuse me for that.

> I made a request;

That is okay, and I said already early on that it will require a lot of
work from you to make it happen, and I explained why I won't put in as
much work: XP is two years past its EOL.

> if your decision is to reject it,

I did no such thing. I rejected the notion that this is a task that the
currently active contributors need to take care of.

So once again: I will welcome any serious contribution to support XP
again. I will not work on this myself.

I hope that clarifies things once and for all,
Johannes