Doesn't work with SourceTree

[VarunAgw]

[andy-5]

Without more information, it is hard to say what exactly is not working. Is there any way you could get a log of the git commands SourceTree is trying to execute? At least, there seems to be a log file according to the documentation.

Does wslgit.exe work when you execute it manually from the command line?

[VarunAgw]

Here is a sample log entry.

  {
    "Command": "git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks rev-list --after 11/29/2018 HEAD --count",
    "Directory": "C:\\test",
    "Status": "Finished",
    "Duration": "00:00:00",
    "CallerContext": "GetCommitCountSinceCommit",
    "Output": "System.ComponentModel.Win32Exception: The system cannot find the file specified\n"
  },

wslgit.exe work fines properly directly, but not when used with SourceTree

[fengcen]

@VarunAgw
I found the solution:

1. Uninstall "Git for windows".
2. You must place wslgit.exe to C:\Program Files\Git\bin\git.exe
3. Add C:\Program Files\Git\bin to the system Path
4. Install "Sourcetree"

[andy-5]

@fengcen Great, thanks for sharing your solution.

@VarunAgw Can you confirm that this works? If it works for you, I guess this issue can be closed.

[VarunAgw]

@fengcen @andy-5

Thanks! It worked. I noticed c:\Program Files is not important here, but Git\bin\git.exe

[transtone]

After update windows 10 to 1903. It works like a charm.

[99linesofcode]

Just to clarify, this issue is caused by SourceTree not able to find the Git binary. It is not necessary to move your wslgit.exe to a certain location OR add it to your $PATH environment variable. Instead, restart SourceTree and it will prompt you to look for the install location of your git.exe, which in my case lives under C:/tools/Git/bin/git.exe. As far as I can tell you can place this anywhere and name it whatever you like.

If you are not presented with a prompt, just start SourceTree without Git support and do the following:

1. From the top menu, navigate to Tools > Options;
2. Click the Git tab;
3. Scroll down to the bottom section named Git version;
4. Hit the System button. If you are not prompted to browse to the install location, hit clear path cache and try again;
5. You can probably check Disable LibGit2 Integration as we are going to use the system installed version and not the portable git version that comes with SourceTree.

Happy coding 👋

Edit: Added screenshot for clarity

[charlwillia6]

So this is still an issue. As of now with SourceTree 3.1.3 and the latest version of WSL Git, if you try to redirect the path to wslgit.exe (or even if it is renamed to git.exe, you get the following:

And the program freezes and you have to kill it. If you try doing a fresh install, this same thing also happens on the "Install" part if you have the environmental variable set to the path. So I am assuming that SourceTree now doesn't like wslgit.exe at all. I can't see to use them together. I had to download GitKraken, which doesn't seem to have any issues at all. SourceTree is just my preferred GUI and I wish I could get it to work.

[andy-5]

That's too bad. Can you maybe try the latest changes of wslgit? Recently, there were some changes to how some special characters are escaped. You can download an alpha build with the latest changes here.

If it does not work, can you please provide the contents of the log file (see above)?

[charlwillia6]

@andy-5 - I reinstalled SourceTree and tried to pick the git.exe (renamed from wslgit.exe) as the default git client and it just froze the installation process. I had to kill SourceTree with the Task Manager. I then tried the install again and selected the embedded git option. Then once SourceTree was installed I then went to the options and tried to change from embedded to system, selected the git.exe in the correct directory and SourceTree froze again.

The only thing in the sourcetree.log file was this:

ERROR [2019-08-28 11:14:43,129] [1] [SourceTree.Analytics.Submission.Gas.GasAnalyticsSubmissionService] [Log] - Hi There! 

I also checked the settings.log file and the last entry was:

DEBUG [2019-08-28 11:15:53,468] [1] [Microsoft.Extensions.Logging.Logger] [Log] - CustomSettings. Saving config...

So I am not getting any errors in the SourceTree logs. Something else I am noticing is this alpha version does not work with Visual Code Insiders either. The only thing in the output there is Looking for git in: C:\Development\Git\bin\git.exe

So this alpha version breaks any integration with Visual Code. And GitLens doesn't work with the stable or alpha version.

[charlwillia6]

I switched back to 0.7.0 and now Visual Code Insiders works fine, except for Git History or GitLens. SourceTree still freezes and has nothing in the logs.

[andy-5]

Thanks for the update. Getting no errors makes it very hard to fix, as I've got no idea what the actual problem is. I'll re-open this issue to keep track of it, though.

Also, thanks for the heads-up regarding VS Code Insiders. I don't currently have an Insiders installation, but the alpha still works for stable VS Code for me, so there seem to be some recent changes to Git in VS Code. Good to keep in mind.

[adrach]

I also just tried 0.7.0 and that did not work for me either. For some reason, SourceTree does not like wslgit executable even when you directly point at it, or if you manually replace embedded version executables with this one

[carlolars]

I have wslgit.exe (0.8.0-alpha-ish) renamed to git.exe in %HOMEPATH%\bin which I've added to the Windows Path. Both VSCode (stable) and SourceTree 3.2.6 picks up and use that git.

@charlwillia6 @adrach have you updated git in WSL? The Ubuntu 18.04 repository has a very old git, v2.7-something I think. To get later versions of git you must add a new ppa (source: https://launchpad.net/~git-core/+archive/ubuntu/ppa):

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update

[charlwillia6]

@carlolars ~ I downloaded the most current "alpha" version of wslgit.exe that I could find (0.8.0 alpha V4) which is here: https://ci.appveyor.com/project/andy-5/wslgit/build/artifacts as of 9/30/2019

I also have Git upgraded already on WSL by using the git-core PPA that you have posted and the version of Git that is installed is 2.23.0. So I do definitely have the most current stable version installed.

VSCode-Insiders does not seem to work with wslgit 0.8.0 alpha-4. VSCode-Insiders complains that "No source control providers registered." I have renamed wslgit.exe to git.exe in my Git/bin directory. If I run Git: Show Git Output, I get Looking for git in: C:\Development\Git\bin\git.exe

I use the Insiders version because of certain compatibilities that are needed for some updated extensions and for also working with the most recent enhancements to WSL 2 and the WSL Remote extensions. I already tried VSCode Stable before and it wasn't working for me with the alpha build then and I don't want to keep installing it just to test it if it isn't going to work with SourceTree anyways.

I also still cannot get SourceTree version 3.2.6 to work with this alpha version of wslgit.exe either. I have tried a clean install several times with files for Atlassian deleted from the AppData directory.

If I open cmd.exe and check the git version there the output does say git version 2.23.0 which suggests that wslgit.exe is working in the Windows command line and so is the PATH environment variable that is pointed to my C:\Development\Git directory.

So my conclusion is that SourceTree does not work with the v0.7.0 or 0.8.0 alpha-4, and VSCode - Insiders does not work with 0.8.0 alpha-4.

[charlwillia6]

@carlolars and @andy-5 ~ I decided to download VSCode 64-bit Stable (v1.38.1) and it too gets stuck at:

Looking for git in: C:\Program Files\Git\cmd\git.exe
Looking for git in: C:\Program Files (x86)\Git\cmd\git.exe
Looking for git in: C:\Program Files\Git\cmd\git.exe
Looking for git in: C:\Users\cwilliams\AppData\Local\Programs\Git\cmd\git.exe
Looking for git in: C:\Development\Git\bin\git.exe

Is this exe corrupt maybe? I even checked if this was a permission issue or something and both my 0.7.0 version and 0.8.0-alpha4 have the exact same permissions. 0.8.0-alpha4 will just simply not work unless it is directly from the command line.

[andy-5]

@charlwillia6 Just to make sure, when you run something like wslgit.exe --version in cmd.exe, what is the exact output?

If there is any additional output besides the git version, e.g. a message from your shell or something similar, VS Code and SourceTree will not correctly recognize the output of git.

Also, have you maybe changed your shell in WSL? There were some issues in the past when another shell than bash was executed.

[charlwillia6]

@charlwillia6 Just to make sure, when you run something like wslgit.exe --version in cmd.exe, what is the exact output?

@andy-5 ~ git version 2.23.0 - This is all that is in the output. The command line treats wslgit.exe as though it is Git itself.

Also, have you maybe changed your shell in WSL? There were some issues in the past when another shell than bash was executed.

I have not changed my shell. Nothing is different in my WSL besides running an update on Git, and running a update on Ubuntu itself.

[charlwillia6]

Eclipse IDE is also another program that is not compatible with wslgit. Just throwing that out there.

[mogzol]

For the record, I previously had issues getting this to work with sourcetree and WSL2, but I just tried again today and it seems to be working perfectly (sourcetree 3.3.8, libgit2 disabled, windows 19569).

The only issue I ran into is that sourcetree requires git.exe to be inside a bin folder. So I originally had wslgit at the location C:\Users\me\Documents\wslgit\git.exe (note that wslgit.exe has been renamed to git.exe), and had that folder in my PATH as well. With that configuration, wslgit worked fine from the command prompt, but sourcetree tried to look for git in C:\Users\me\Documents\bin\git.exe (which didn't exist).

To fix this, I had to move wslgit to C:\Users\me\Documents\wslgit\bin\git.exe, and update my PATH to that as well. After doing that, sourcetree correctly found the executable and is working flawlessly, both with repositories in my windows filesystem and those under \\wsl$\.

[andy-5]

Great, thanks for the feedback. The next release, currently in development in the develop branch, will contain a small install.bat script that creates a folder structure similar to Git for Windows with bin and cmd directories, as this seems to be required/better supported by multiple tools.

[charlwillia6]

The only issue I ran into is that sourcetree requires git.exe to be inside a bin folder. So I originally had wslgit at the location C:\Users\me\Documents\wslgit\git.exe (note that wslgit.exe has been renamed to git.exe), and had that folder in my PATH as well. With that configuration, wslgit worked fine from the command prompt, but sourcetree tried to look for git in C:\Users\me\Documents\bin\git.exe (which didn't exist).

To fix this, I had to move wslgit to C:\Users\me\Documents\wslgit\bin\git.exe, and update my PATH to that as well. After doing that, sourcetree correctly found the executable and is working flawlessly, both with repositories in my windows filesystem and those under \\wsl$\.

I confirm this is now working in SourceTree 3.3.8. However, I didn't change my folder structure, I always had git.exe and wslgit.exe in a bin folder. So, the updated version of SourceTree must be compatible with WSLGit now. I also disabled the libgit2, and everything seems to be working.

[charlwillia6]

I spoke too soon. While SourceTree works somewhat with WSLGit, it breaks other things like SourceTree's ability to use OpenSSH, or even Pageant to check SSH keys with git repositories. While this isn't a problem with WSLGit and more of a problem with SourceTree just not being compatible with WSL in general, getting WSLGit to work with SourceTree doesn't fix all the other issues that are going to happen because of the ssh-agent issues that will follow. Remote links are broken on some of my projects too. If you decide to just use HTTPS and never use ssh for authentication then SourceTree "kind of works".

I also had to get the authentication working on the WSL side because adding your credentials in SourceTree just doesn't work. So, after configuring your credential.helper store in WSL(Ubuntu, or whatever), then saving your Bitbucket or GitHub credentials, only then will SourceTree play nice.

Also, when you open a terminal from SourceTree it will just be a normal Windows cmd.exe terminal. You would still need to activate/run wsl.exe after launching. There are no terminal configurations in SourceTree.

There really is too many issues with trying to get SourceTree to work as a decent client with WSL, and getting it to be compatible with Git is just the first annoyance.

[LittleHoopoe]

This solved my error(but first what happend):

I installed Win Service Open-SSH-Client and added the ssh-agent to the system like this (all in Powershell (admin)):
git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe
Get-Service -Name ssh-agent | Set-Service -StartupType Automatic
ssh-agent
ssh-add
the good part: vscode now can push pull ssh git repositories
the bad part: sourcetree can't anymore (my sourcetree Git Version was set to System)
To solve the problem:
I "Updated Embedded" but not sure if this was necessary and switched to Embedded. After confirming everything, the cmd.exe of sourcetree popped up and I could confirm my ssh passphrase. Now sourcetree works fine (using the embedded Git Version) and VsCode works as well (using the system git version). Hope this will help someone.

[dhanar10]

Here is what works for me:

1. Put wslgit.exe to C:\wslgit\cmd\wslgit.exe
2. Put install.bat to C:\wslgit\install.bat
3. Open cmd.exe in C:\wslgit and run install.bat
4. Install Sourcetree 3.3.9 and point it to C:\wslgit\cmd\git.exe

Notes:

1. I am using Ubuntu 20.04 WSL2 with git, git-lfs, git-flow coming from the default repo
2. Automatically start ssh agent when Sourcetree starts is disabled.
3. I need to use workaround to make interactive rebase work Interactive Rebase/Commit Squashing not working inside Sourcetree #125 (comment)

[poniatowski]

Does the Source Tree work for anyone here? Does anyone manage to solve the issue?

[GuyPaddock]

I tried the steps from #61 (comment) to no avail in SourceTree 3.4.16 with Ubuntu 22.04.3 LTS, Git 2.34.1, and WSL 2 with this version info:

WSL version: 2.0.9.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.2861

It appears that SourceTree's embedded Git installs Portable Git under %USERPROFILE%\AppData\Local\Atlassian\SourceTree\git_local (e.g., C:\Users\Guy\AppData\Local\Atlassian\SourceTree\git_local), with 4 copies of git.exe:

1. cmd/git.exe
2. bin/git.exe
3. mingw32/bin/git.exe
4. mingw32/libexec/git-core/git.exe

Of those, SourceTree only seems to care about the first one (under cmd/git.exe). I confirmed this by deleting the bin/ folder and restarting SourceTree, and it did not seem to care that bin/git.exe was missing. Meanwhile, the MinGW32 copies are used for the Bash terminal.

With SourceTree running I was briefly able to force SourceTree to use WSLGit by doing the following:

1. Disabling LibGit2 integration.
2. Converting all my bookmarks in bookmarks.xml to use UNC paths instead of a mounted drive letter (i.e., normally I mount \\wsl$\Ubuntu as my W:\ drive, but for this I had to switch the paths to be under \\wsl$\Ubuntu).
3. Replacing %USERPROFILE%\AppData\Local\Atlassian\SourceTree\git_local\cmd\git.exe with the wslgit.exe executable.
4. Toggling SourceTree to use the "System" GIT installation and having it fail, resulting in it toggling back to the git.exe I had replaced from the Embedded copy.

This worked for a single session, but as soon I restarted SourceTree, it wanted to reinstall embedded Git again.

I did notice the following errors in sourcetree.log, so I tried installing Git Flow inside WSL but that didn't fix the issue:

ERROR [2024-01-09 10:59:52,218] [PriorityScheduler: 0] [SourceTree.Repo.RepoHandlerGitOld] [Log] - Unable to get Git-Lfs version: fatal: 'lfs' appears to be a git command, but we were not
able to execute it. Maybe git-lfs is broken?

[GuyPaddock]

Okay, I take it back -- I found a workaround, but this feels brittle and hackish:

1. Disable LibGit2 integration in SourceTree settings.
2. Install Git Flow and Git LFS inside WSL (e.g., sudo apt-get install git-flow git-lfs).
3. Convert all your bookmarks in bookmarks.xml to use UNC paths instead of a mounted drive letter (i.e., normally I mount \\wsl$\Ubuntu as my W:\ drive, but for this I had to switch the paths to be under \\wsl$\Ubuntu).
4. Replace %USERPROFILE%\AppData\Local\Atlassian\SourceTree\git_local\mingw32\bin\git.exe with WSLGit (e.g., so wslgit.exe should get copied to a path like C:\Users\Guy\AppData\Local\Atlassian\SourceTree\git_local\mingw32\bin\git.exe.

DO NOT replace any other copies of git.exe that you find under %USERPROFILE%\AppData\Local\Atlassian\SourceTree\git_local. At a minimum, if you replace git_local\cmd\git.exe, SourceTree will report that Embedded Git is not installed. I believe that SourceTree does a digital signature check of the Git executable and refuses to use it if the signature does not pass the check.

I figured this out by realizing that the file size of git_local\cmd\git.exe is only 46 KB while git_local\mingw32\bin\git.exe is 3.76 MB, so the former can't really be Git. Rather, it looks like git_local\cmd\git.exe is a digitally signed wrapper around MingW that loads the real Git executable under git_local\mingw32\bin\git.exe. So, by replacing the MingW copy of Git with WSLGit, the digital signature check that SourceTree performs will pass AND it will actually use Git inside WSL.

I have further confirmed that the Linux version is being used by enabling core.filemode in my repo and refreshing SourceTree. When I do this, any changes to file modes I make to the files inside WSL reflect as changes in SourceTree. If I change the permissions on the files in WSL to match what they are in the repo, the changes go away. Normally, with the Windows version of Git, this is not possible because Windows doesn't support the Posix permissions.

Versions Reported

Adding to the weirdness, SourceTree appears to get the version information about Git from the digital signature rather than by running git --version but does get the version of Git LFS by running git lfs --version.

Before Version Swap

Here are the versions reported of everything BEFORE I swapped the MingW Git for WSLGit:

Component	Version
SourceTree Settings Window	Embedded Git version 2.39.1 + git-lfs v3.3.0
MinGW32 Terminal (launched from SourceTree)	git version 2.39.1.windows.1
WSL/Ubuntu	git version 2.34.1 + git-lfs/3.0.2 (GitHub; linux amd64; go 1.18.1)

After Version Swap

And here's what gets reported afterwards:

Component	Version
SourceTree Settings Window	Embedded Git version 2.39.1 + git-lfs v3.0.2
MinGW32 Terminal (launched from SourceTree)	git version 2.34.1
WSL/Ubuntu (no change expected)	git version 2.34.1 + git-lfs/3.0.2 (GitHub; linux amd64; go 1.18.1)

[GuyPaddock]

Regarding the issues mentioned about using this with Pageant, I use the wsl2-ssh-pageant adapter, which, despite not being maintained in the last two years and having several reports in its issue queue from users who say it stopped working for them, is still working for me even on Windows 11 version 10.0.22631 build 22631. I have been using the WSL2 Pageant since 2022 since it works with SSH and Git from within WSL.

I have the binary installed in my Windows home folder under /bin (e.g., %USERPROFILE%\bin\wsl2-ssh-pageant.exe), and then I have this snippet in my .bashrc file in WSL (change MY_WINDOWS_USER_NAME to your Windows username as it appears under C:\Users):

# Use Pageant in WSL for SSH keys.
export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
windows_username="MY_WINDOWS_USERNAME"

if ! ss -a | grep -q "$SSH_AUTH_SOCK"; then
  rm -f "$SSH_AUTH_SOCK"
  # wsl2_ssh_pageant_bin="$HOME/bin/wsl2-ssh-pageant.exe"
  wsl2_ssh_pageant_bin="/mnt/c/Users/${windows_username}/bin/wsl2-ssh-pageant.exe"
  if test -x "$wsl2_ssh_pageant_bin"; then
    (setsid nohup socat UNIX-LISTEN:"$SSH_AUTH_SOCK,fork" EXEC:"$wsl2_ssh_pageant_bin" >/dev/null 2>&1 &)
  else
    echo >&2 "WARNING: $wsl2_ssh_pageant_bin is not executable."
  fi
  unset wsl2_ssh_pageant_bin
fi

As long as I start at least one Ubuntu terminal in my Windows session, WSL can use credentials from PuTTY's Pageant agent.

[andy-5]

@GuyPaddock Glad you got it working, and thanks for sharing your solution.

I wonder why SourceTree does not pick it up from other locations (as described by others above), and you were forced to replace its internal Git executable. But it's good that you've at least found some solution.

[GuyPaddock]

@andy-5 My speculation is that it's doing digital signature checking to ensure that it's only running a command it recognizes. But, since this is an Atlassian product, they only implemented 50% of the solution and aren't checking the signature of the underlying chain-loaded Git executable 🙄