[ANNOUNCE] Git for Windows 2.25.0

[Johannes Schindelin]

Dear Git users,

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

https://gitforwindows.org/

Changes since Git for Windows v2.24.1(2) (December 10th 2019)

New Features

* Comes with Git v2.25.0.
* Comes with GNU Privacy Guard v2.2.19.
* Comes with Git LFS v2.9.2.
* When upgrading Git for Windows, by default the installer now only
shows pages with previously-unseen options.
* Comes with cURL v7.68.0.

Bug Fixes

* The startup file for GNU nano, which had been included with DOS
line endings (and therefore upset nano) is now included with Unix
line endings again.
* Git for Windows now fails as expected when trying to check out
files with illegal characters in their file names.
* Git now works properly when inside a symlinked work tree.
* Repositories with old commits containing backslashes in file names
can now be fetched/cloned again (but Git will still refuse to check
out files with backslashes in their file names).
* Git GUI can now deal with uninitialized submodules (this was a
Windows-specific bug).
* It is again possible to clone repositories where some past revision
contained file names containing backslashes (Git will of course
still refuse to check out such revisions).

Filename | SHA-256
-------- | -------
Git-2.25.0-64-bit.exe | 6ffb0674a5f5fec2a328dd40456ede87ed3c7de653ecd6950f9cf132bca2f94c
Git-2.25.0-32-bit.exe | 6c02f1a1f95e286df8b87c2812c9460f4c2d333bab7a654751e01e9801994045
PortableGit-2.25.0-64-bit.7z.exe | c191542f68e788f614f8a676460281399af0c9d32f19a5d208e9621dd46264fb
PortableGit-2.25.0-32-bit.7z.exe | 5ad97ff1e806815aa461ab39794e42455f19c9a6ead08ca0e5b8f2bb085214a6
MinGit-2.25.0-64-bit.zip | 30bbd4ba6ca21fe97d43397a3d4e0e24be6ae2660b517cc1b96350195e48adea
MinGit-2.25.0-32-bit.zip | 0075b80e868cff4a00f7d328c9406bd35dbebbd28ef2f5f594dde03e2256a88a
MinGit-2.25.0-busybox-64-bit.zip | cd1e0e2fe8b2dee9e1ffd826501c1453532e01be5739f364a588560b26f6dc91
MinGit-2.25.0-busybox-32-bit.zip | 8edbcef08bdf206c890b7e17bcfb1f355ee6304e9b80445b076200c14efa71c2
Git-2.25.0-64-bit.tar.bz2 | af4cf57901098f3f36a4a75e4c93ce1078553433e69fd7a54b2a872bc8c2c7a1
Git-2.25.0-32-bit.tar.bz2 | 977606f93b58146126dc2c7b7ad19985eaa812852b08dd3354b5e40887cccd34
pdbs-for-git-64-bit-2.25.0.1.7c71c859c9-1.zip | 700f817cc66ae46309d8ad0bf535122b11276e1be67ccd91acfd9b54bf3a6fe5
pdbs-for-git-32-bit-2.25.0.1.7c71c859c9-1.zip | 7ee0a2a2a6a755169821b6e58bf313edf0436bbf26c5cbfb8efc2d7042488ffa

Ciao,
Johannes

[Michael W Powell]

On Monday, January 13, 2020 at 5:02:06 PM UTC-5, Johannes Schindelin wrote:

Dear Git users,

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

If I read the reports and feedback from the prior release, it seems like the prior one was a bit troubled, so to speak. Is this one any more stable than the last? 

[Philip Oakley]

On Tuesday, January 14, 2020 at 2:56:07 AM UTC, Michael W Powell wrote:

On Monday, January 13, 2020 at 5:02:06 PM UTC-5, Johannes Schindelin wrote:

Dear Git users,

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

If I read the reports and feedback from the prior release, it seems like the prior one was a bit troubled, so to speak. Is this one any more stable than the last? 

**

I'd expect it to be a lot more stable. I.e. back to regular stability.

The previous 'issue' was that 'we' attempted to solve a long standing problem with compatibility of filenames between platforms. The initial solution was good, but incomplete, and had some unfortunate side effects for some users. These have all been ironed out, and user reports are good!

So confidence is high that it is back to 'open source as usual' (cf business as usual..)

**

Philip

['we' => major points to the maintainer dscho, who does most of the work. Support always welcome]

[Ja Ru]

Why the version of Gitflow is different on two different Windows hosts, where, the version of GFW is the same... v2.25.0.windows.1

One Gitflow had the suffix -dev0 appended to the version; and the other did not have that.

Did the GfW devs just slip that label change for the same build of Gitflow-AVH, and not bother mentioning in the release notes?

Thx!

[Johannes Schindelin]

Hi Ja Ru,

I bet that there is a `git-flow` in the search path in one of those
setups, maybe installed into `~/bin/`. Open a Git Bash, call `which
git-flow` to find out.

Ciao,
Johannes

[Ja Ru]

NAILED IT!
Very helpful!

What is the recommended way to remove one i don't want?

To examine the good one that I want to keep, why can't I find the file system location of /mingw64/bin/git-flow  ?

I am not a regular Windows user. Open to Windows admin advice. ;-)

Thank you!!

[asmwarrior]

I see an error when I use the Git GUI to add some files to the index. (I'm using 64bit git-for-windows 2.25.0, and Windows 7)

When I first click on the file to add this file to the index, I see a CRLF related issue, see the image below:

I see this kind of warning many times, and I just click the "Continue" button, and then I see another error dialog, see image show below:

Any hints? Thanks.

[Johannes Schindelin]

Hi,

On Fri, 17 Jan 2020, Ja Ru wrote:

> What is the recommended way to remove one i don't want?

Why, yes.

> To examine the good one that I want to keep, why can't I find the file
> system location of /mingw64/bin/git-flow ?

/mingw64/bin/ is never the correct location for git-flow. /usr/bin/ is.

Ciao,
Johannes

[Johannes Schindelin]

Hi,

Is this the same issue as
https://github.com/git-for-windows/git/issues/2469? If so, there should be
the solution in this ticket right there. You might also want to consider
reporting this issue to the Git GUI maintainer.

Ciao,
Johannes

[Ja Ru]

Hello,

I appreciate the advice. :-)

Is it a special hidden directory. I have trouble finding that path in the Windows file system...

Perhaps this (/mingw64/bin/git-flow) is down under some cygwin directory?

Thank you!

[Johannes Schindelin]

Hi,

On Mon, 20 Jan 2020, Ja Ru wrote:

> I appreciate the advice. :-)
> Is it a special hidden directory. I have trouble finding that path in the
> Windows file system...
> Perhaps this (/mingw64/bin/git-flow) is down under some cygwin directory?

There is no `/mingw64/bin/git-flow`. Unless you copied it there. Because
it is an incorrect location for that script. The correct location is
`/usr/bin/git-flow` (you can check via `ls -l /usr/bin/git-flow` in your
Git Bash).

Ciao,
Johannes

>
> Thank you!
>
>
> On Mon, Jan 20, 2020 at 3:43 AM Johannes Schindelin <
> Johannes....@gmx.de> wrote:
>
> > Hi,
> >
> > On Fri, 17 Jan 2020, Ja Ru wrote:
> >
> > > What is the recommended way to remove one i don't want?
> >
> > Why, yes.
> >
> > > To examine the good one that I want to keep, why can't I find the file
> > > system location of /mingw64/bin/git-flow ?
> >
> > /mingw64/bin/ is never the correct location for git-flow. /usr/bin/ is.
> >
> > Ciao,
> > Johannes
> >
>

> --
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/CADtDgkfS1MYOou6%3D-2rLKc%3Dze73FUJJCai5%3D4%3Df8cGFu%3DFL50Q%40mail.gmail.com.
>

[Ja Ru]

Hello Johannes,

There is no `/mingw64/bin/git-flow`. Unless you copied it there. Because
it is an incorrect location for that script. The correct location is
`/usr/bin/git-flow` (you can check via `ls -l /usr/bin/git-flow` in your
Git Bash).

I would agree with you completely if I were not experiencing a different outcome.

I genuinely appreciate the perspective. It is 99% certainty that an installer wrote this file: /mingw64/bin/git-flow

Maybe it happens when Git for Windows is not run as Admin?? I'm not exactly proficient on Windows compared to Unix.

It will remain a mystery.

WIN-JURU+juru@WIN-JURU MINGW64 /mingw64
$ which git-flow
/mingw64/bin/git-flow

WIN-JURU+juru@WIN-JURU MINGW64 /mingw64
$ git flow version
1.12.4-dev0 (AVH Edition)

I know this is not a windows admin support group. I am surprised that the `which` command returns this location compard to the location that folks say is the correct one. I cannot find that file path on the file system.

Thx!

[Johannes Schindelin]

Hi Ja,

On Tue, 21 Jan 2020, Ja Ru wrote:

> There is no `/mingw64/bin/git-flow`. Unless you copied it there. Because
> > it is an incorrect location for that script. The correct location is
> > `/usr/bin/git-flow` (you can check via `ls -l /usr/bin/git-flow` in your
> > Git Bash).
> >
>
> I would agree with you completely if I were not experiencing a different
> outcome.
>
> I genuinely appreciate the perspective. It is 99% certainty that an
> installer wrote this file: /mingw64/bin/git-flow

Hmm. I have a rather pristine installation over here, and I get this:

$ which git-flow
/usr/bin/git-flow

> Maybe it happens when Git for Windows is not run as Admin?? I'm not
> exactly proficient on Windows compared to Unix.

No, the list of files and their exact paths does not change whether you
run as an admin or not. Besides, the installer should always run in
elevated mode, we do not support installing Git for Windows for only the
current user (at least not _yet_, I would be open to accepting PRs to
allow that).

> It will remain a mystery.
>
> WIN-JURU+juru@WIN-JURU MINGW64 /mingw64
> $ which git-flow
> /mingw64/bin/git-flow
>
> WIN-JURU+juru@WIN-JURU MINGW64 /mingw64
> $ git flow version
> 1.12.4-dev0 (AVH Edition)
>
> I know this is not a windows admin support group. I am surprised that the
> `which` command returns this location compard to the location that folks
> say is the correct one. I cannot find that file path on the file system.

Maybe you want to inspect the date of that file? `ls -l
/mingw64/bin/git-flow` should tell you.

My suspicion is that this was installed manually at some point, and was
simply not removed when upgrading Git for Windows (because Git for
Windows' uninstaller takes pains in removing _only_ the files it owns).

So the best remedy I have for you is to simply remove this file. After
that, open a new Git Bash and verify that `which git-flow` finds the
`/usr/bin/` one.

Ciao,
Johannes