SourceTree and Tortoise Git do not detect an installed git for windows.

[swalter]

Yesterday I've installed the RC2 of the current release to test this on my private development environment before I use it at work.
After installing the 64bit version I entered the tortoise git settings to see, witch version gets detected here. I got a dialog here mentioned that it was tortoise was not able to detect the correct version string.
The label showing the version installed however showed version 2.4.3.1.
Ignoring this fact I started SourceTree. Short time after that the dialog to choose a versioning tool popped up.
So it seems there is a problem right now to detect the installed version of your tool. Maybe this problem does not exist using the 32bit version that was not tested by me.

[YueLinHo]

/cc @csware @ch3cooli

[nalla]

See #152. This is due to the fact that the /bin directory dropped. There is a workaround described in https://jira.atlassian.com/browse/SRCTREEWIN-3226

[dscho]

I have an idea. We could re-add the /bin/ directory and put copies of the Git wrapper there, git.exe, git-receive-pack.exe and git-upload-pack.exe. We could also copy an appropriately edited git-cmd.exe as bash.exe there so that the same command-lines work as before.

@nalla what do you think?

[nalla]

@dscho I think its a sound plan. Because its just the Git wrapper it would be a minimal size impact. Best let the inno setup script handle that.

[dscho]

Best let the inno setup script handle that.

I'd actually also like the Portable Git users to benefit (remember, a variation of Portable Git is available with GitHub for Windows, and GitHub essentially sponsored all of the Git for Windows 2.x push).

[nalla]

If I remember correctly SourceTree also uses an internal portable release that will eventually be pushed to Git for Windows 2.x. So that indeed makes sense.

So I think both release scripts have to be adapted then.

[shiftkey]

I'd actually also like the Portable Git users to benefit

Given the downstream users control which version of PortableGit they're using, any extra hoops to jump through aren't really worth it. Adapting to the new structure isn't that hard, but if environments have to support 1.9.x and 2.x at the same time perhaps the workaround is necessary.

[dscho]

I implemented this and published it as part of the 3rd release candidate.

Please test, everybody!

[nogaff]

Seems to work fine for me with the current SourceTree release except that SourceTree's "Terminal" button tries to open a command prompt via /bin/sh.exe which obviously fails.

I got it to work properly by creating a symlink /bin/sh.exe -> /bin/bash.exe. Perhaps an sh.exe redirector needs to be put in /bin as well?

[dscho]

@nogaff please note that this commit should fix the issue (not by symlinking because that does not work in general, but simply by copying; it's just 29kB, so I think that's fine).

[JoshSchreuder]

FYI - Sourcetree's current beta worked around this issue (https://www.sourcetreeapp.com/update/WindowsReleaseNotes_public_beta.html):

SRCTREEDEV-108 Support v2.x, 32-bit or 64-bit of Git for Windows as a System Git. NB. requires use of putty/pageant rather than ssh-agent.exe unless running as administrator.

[dscho]

@JoshSchreuder thanks for the update!