GitFlow stopped working after Git 2.5 update

[veccie]

I recently updated my Git installation to the new v2.5, but after that GitFlow stopped working. Everything else Git related in VS 2015 works fine.

In the output I can see that it executes the command, but nothing happens and no errors are thrown. This happens for all three commands: feature, release and hotfix.

I've tried removing and reinstalling the extension but that doesn't help.

Is there a log where I can see what's going on or something else I can do to make it working again?

[alexhardwicke]

I have the same problem. I've done a little research, and it looks like git flow itself at the command line level is somewhat broken with Git 2.5.0 - see https://github.com/petervanderdoes/gitflow/issues/210 for more details.

As the above issue says, 32-bit Git 2.5.0 with Git Flow installed in \usr\bin works. I imagine that, to fix GitFlow.VS, it just needs to look and work in \usr\bin instead of \bin.

I was going to do a pull request but I can't get the extension to build (I think I'm missing the extensibility tools) and I don't have the time to spare to get the build working. Hopefully this'll help @jakobehn fix it, though.

[jakobehn]

Thanks for reporting this guys. I have made a change to how the GitFlow extension locates the installation path of msys-git. I have tried it on a couple of machines with v2.5 installed. The experience after upgrading the extension will be that you are prompted to install GitFlow again, since the files need to be copied to the usr/bin location. I would be great to have some extra tests for this version, so I've published a draft release here with the vsix files. Would you mind trying these out before I publish them to the gallery?

The release is here https://github.com/jakobehn/GitFlow.VS/releases/tag/v0.10.10

Thanks!

[veccie]

Cool. I've made a quick test on two projects. The first project prompts me to install GitFlow, the second project detects that it has been installed. I've tried making a few features and a release. So far so good :+1:

Thanks for the quick update.

[jakobehn]

Thanks! I do however see an issue when initializing a repo from the extension. I haven't yet found what causes the problem, but I get an error when running initialize. Does this work for you?

[alexhardwicke]

I get the same problem when doing an initialise. Command-line works fine, and GitFlow.VS updated the instant I did a git flow init by hand.

The error I get in GitFlow.VS is:

Fatal: Local branch 'master

The rest of the extension works as it should, I think - I just did a quick feature-finish-release-finish and it all looks good.

[jakobehn]

Thanks for confirming. This problem must be related to upgrading to the Git for Windows 2.X version, I tried to install the existing version of the extensoin from the gallery and it gives me the same error. I have to dig into this, it's very strange that the exact same command works from command line

[veccie]

Yeah, I get the same fatal error when initializing. Command-line works.

[jakobehn]

OK, I think I solved the problem. For some reason, git doesn't parse the newline character the same way anymore. Previously i used the WriteLine method (that uses the Environment.NewLine for new line characters), but i had to switch to using Write() + "\n". I tested both on the older verison of msysgit (1.9) and 2.5, and it works on both now. I'll upload a new version (0.10.11.0) to the gallery now. Thanks for your help

[Pitterling]

I updated to Git for Windows 2.5 64bit as recommended. GitFlow reports now "Could not locate Git for Windows". I reinstalled Git and GitFlow, but the error still occurs. SourceTree is working fine.

Is there any logfile to check for the error ?

[jakobehn]

Sorry, you need to install the 32-bit version of git.

[Pitterling]

Whats the matter with 64bit? SourceTree is also 32bit, but can use 64 git. It is just the path to the executable, right?

[jakobehn]

Yes, I just haven't fixed the part that locates where Git is installed. Will do that. Thanks for reporting

[jakobehn]

Actually it does check for the 64-bit version of Git, I just checked the code and also tried it on a machine with only 64-bit version of git installed. Where did you install it, e.g. local path?

[Pitterling]

Standard Installation: "C:\Program Files\Git" . Is there a log file with further information? Thx for looking into this.

[jakobehn]

Unfortunately no. That is strange, the code (https://github.com/jakobehn/GitFlow.VS/blob/master/GitFlow.VS/GitHelper.cs) does check both x86 and x64 paths, as well as PATH variables and registry settings to find the Git installation path.

[Pitterling]

I checked the different code pathes ... first of all, i had a remaining invalid PATH entry from a former git installation pointing to the wrong directory. But problem is not solved. Actually the registry eval code as well as the installation path eval code should find my installation, but it still reported as error.

There is another check for usr/bin ... var binPath = Path.Combine(installationPath, "usr/bin"); I have a such a subdirectory "C:\Program Files\Git\usr\bin" but there is no git executable in it. I renamed the usr directory to end up with "C:\Program Files\Git\bin" following your coding, this contains git.exe. But still no luck ... what do you finally expect in the directory?

[Pitterling]

i traced with procmon what is going on behind the scenes. It seems that the 64bit code pathes are not executed. Registry: HKLM is searched only for 32bit, the 64bit tree is searched within HKCU and of course not found, because it is in HKLM Directory: Only the 32bit "Program Files (x86 )" folder is searched for git, but not the 64bit "Program Files" folder

[jakobehn]

Thanks a lot for digging into this! Could you just verify which version of the GitFlow extension you have installed?

Also: Can you check if you still have the Git folder below Program Files (x86)? Since GitFlow installs some files there, the folder is not completely removed when uninstalling Git

[Pitterling]

version 0.10.12.0 and there is no Git folder below Program Files (x86).

[jakobehn]

Could you try this pre-release version to see if it helps? I've added some existence checks for the paths found in the registry.
https://github.com/jakobehn/GitFlow.VS/releases/tag/v0.10.13

[Pitterling]

I tried, but no change. I looked to your coding changes: No one would apply for me. 1st i cleaned my PATH variable. The procmon output has shown that it is not accessing the 64bit registry/programfiles values. I think the problem is that you are running in the context of Visual Studio which is still a 32bit application, right?. Therefore the 32bit "emulation layer" will always return the 32bit registry hive as well as the 32bit "Program Files" which is "Program Files (x86)" on 64bit Windows...

More information: https://social.msdn.microsoft.com/Forums/vstudio/en-US/37e798f5-1b9b-42ce-89af-486ee3531c0b/32-bit-app-how-to-get-cprogram-files-directory-using-environmentgetfolderpath?forum=csharpgeneral

The last reply proposed something like this in VB for the 64bit part: RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64).OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion").GetValue("ProgramFilesDir")

[jakobehn]

This issue should be fixed in the latest version that I just uploaded (1.0.3.0) where I check the reg key that is now being created by msysgit.

Please let me know if this is still an issue

[Pitterling]

still does not work. It is still looking at the wrong place. I'm using the 64bit GitforWindows. The registry key is HKLM\Software\GitForWindows. VisualStudio is looking here: HKLM\SOFTWAREWOW6432Node\GitForWindows (traced with procmon) see also my post from Sept 1st

[jakobehn]

Strange, I also use 64-bit version of Windows for all testing, and I verified that the old version did not work with the latest version of Git for Windows, and after the update it worked correctly.

I'll look into it later today, sorry for the inconvenience

[Pitterling]

I'm also using the 64bit GitForWindows version as recommended. Probably you have the 32bit version? No probs, try to help as much as possible.