Git 2.5.1 (x64) Installer freezes at end of installation

[docrinehart]

The installer seems to work fine until the end of the installation process. It simply stops doing anything. It isn't marked as "Not-Responding" by task manager, and shows nothing but a non-changing memory usage. I'm attempting to install from 2.4.6 RC5 on a Windows 10 VM in Parallels. My system is a MacBook Pro Retina running Yosemite 10.10.5.

[dscho]

Do you have a C:\Program Files\Git\usr\bin\git.exe perchance?

[dscho]

Oh, and could you run Sysinternals' Process Monitor to find out which executable is waiting?

[docrinehart]

I don't have a git.exe at that path... And I'll give it a shot later if I get a chance to look at that process monitor. After a force quit, it seems to work fine from the command line and source tree. Source Tree also sees it as the proper version.

[dscho]

Still, the installation did not finish, so I would not be surprised if a subset of the functionality does not work. Now that it is force-quit, it is hard to do a live analysis anyway, so can you reinstall and see whether it hangs again?

[docrinehart]

I'll try as soon as I have a chance.

[dscho]

No dice yet, eh?

[cbo100]

I just had this problem.

Poked around in procmon for a while with the hung install running.

Observations:

• Two Git-2.5.1-*.ex running
• Two Git-2.5.1-*.tmp running
• ssh-agent running
• ssh-add running
• No events from any of these processes were being generated in procmon.
• Killed ssh-agent did nothing
• Killed ssh-add caused the installer to continue, giving me the "finish" screen.

I seem to be left with a working installation. But not a git.exe in C:\Program Files\Git\usr\bin\

Some info:

• Previous install was a 1.9 in Program Files (x86)\Git
• This install was 2.5.1 64 bit in Program Files\Git
• There is a git.exe in C:\Program Files\Git\bin\

More observations:

• While writing this up I tried reinstalling 2.5.1 again
• Hung again
• This time, I see the last event related to the installer is ssh-add reading/closing my .ssh/id_rsa
• Then nothing. Again kill ssh-add and installer "finishes"

Hunch

• My existing id_rsa is passphrase protected. Could it be prompting me for my passphrase on some hidden console?

[cbo100]

I think I confirmed my hunch.

Just tried another reinstall after moving my id_rsa, finished without a hitch.

My .bashrc has a line which sources a load-ssh-agent script that runs my ssh-adds. I guess that's it.

The old (1.x) installer never hung on this though.

I guess this PR is the change:

git-for-windows/build-extra#52

Is a quick flash of a tty that bad if it would prevent this (assuming the tty that flashed up would be interactive and accept my passphrase).

[dscho]

Ah, the crucial bit is probably a custom $HOME/.bash_profile or $HOME/.profile that calls ssh-agent?

[cbo100]

Yeah, that seems to be it, combined with the ssh key being passphrase protected.

Maybe these post install scripts could run on first run of the Git Bash prompt rather than during the installer?

[dscho]

Maybe these post install scripts could run on first run of the Git Bash prompt rather than during the installer?

No, that was exactly the problem we tried to solve.

I guess we will have to try to redirect stdin when running the initial Bash session.

@cbo100 I would really appreciate if you could test the following (I am really busy juggling three other bugs right now):

1. download and install the Git for Windows SDK
2. make an installer
3. edit this line by inserting a </dev/null after the -c exit
4. make another installer
5. test that installer

That would really be helpful.

[docrinehart]

Sorry for the delay. I was out of town this weekend, and been playing catch-up for a couple days. I'll give that a shot as well this afternoon.

[docrinehart]

Forgive my unfamiliarity with the scripting language, but that should be part of the arguments like so, right?

if not Exec(Cmd, '--login -c exit </dev/null', AppDir, SW_HIDE, ewWaitUntilTerminated, i) then begin

It builds and runs, but hangs at the same place. I can try again if I inserted that incorrectly.