GitFlow stopped working after Git 2.5 update about gitflow.vs HOT 25 OPEN

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 petervanderdoes/gitflow-avh#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.

from gitflow.vs.

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!

from gitflow.vs.

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 👍

Thanks for the quick update.

from gitflow.vs.

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?

from gitflow.vs.

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.

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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 ?

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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?

from gitflow.vs.

Standard Installation: "C:\Program Files\Git" . Is there a log file with further information?

Thx for looking into this.

from gitflow.vs.

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.

from gitflow.vs.

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?

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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

from gitflow.vs.

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")

from gitflow.vs.

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

from gitflow.vs.

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\SOFTWARE*WOW6432Node*\GitForWindows (traced with procmon)
see also my post from Sept 1st

from gitflow.vs.

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

from gitflow.vs.

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.

from gitflow.vs.