I'm using SmartGit on Windows 10 and I can't get wslgit.exe working with this application. I get this error:

Any idea why this is happening? It works on the command line:

Am I doing something wrong?

Running Windows 10 with the Fall Creators update, removed the password requirement as per the documentation, and VSCode sort knows a version control system is in place, but it looks broken, and files are never flagged as dirty, and git blame doesn't work.

Is this potentially because the path to my files contains a space in it?

Windows Insider builds 17063 and later include a wslpath tool to translate between Linux and Windows style paths. This could be used in place of the current translate_path_to_unix and translate_path_to_win implementations. The options are as follows:

-a    force result to absolute path format
-u    translate from a Windows path to a WSL path (default)
-w    translate from a WSL path to a Windows path
-m    translate from a WSL path to a Windows path, with ‘/’ instead of ‘\\’

Source: https://blogs.windows.com/windowsexperience/2017/12/19/announcing-windows-10-insider-preview-build-17063-pc/

Just recently, I noticed that Fork was not showing the 'Commit/Changes/File Tree' pane, with an error message: /bin/bash: !--RevisionMessageEnd--; No such file or directory

At first, I thought that the issue is with Fork, so I tried reinstall Fork, but the issue still persist.

The message disappeared only when I changed the Git Instance under preference to the default git that was include with the app.

So it's suggesting to me that the issue is with the wslgit symlink.

I'm using Fork Version 1.80

Hope you can help me,

Thanks

Hi, I'm not sure if I'm missing something but the .exe doesn't work at all, I have downloaded it and placed in my PATH and I can't execute git from Powershell nor VSCode, no matter what command I pass to wsl it just doesn't output anything.

I'm running WIndows 10 Pro 1709. Using the new WSL enviroment (Ubuntu Distribution)

I keep getting the following Windows error whenever I run wslgit.exe:

The application was unable to start correctly (0xc000007b)

Some searching suggested that it is usually the result of mixing 32-bit and 64-bit environments. However, I'm using a 64-bit Windows 10 Pro build 17134.286, so that's probably not it.

The output of wslconfig.exe /l is as follows:

Windows Subsystem for Linux Distributions:
Ubuntu (Default)

It's the one from the store, installed just a couple of months ago. I am able to run wsl.exe from a command line just fine, but not wslgit.exe.

WSLgit is forcing a conversion of data from git (diffs, key/values, files, status, binary, ...everything) from unknown encodings into UTF-8. This can result in corruption of data.

As per GIT documentation:

• Git at the core level treats path names simply as sequences of non-NUL bytes, there are no path name encoding conversions.
• Commit log messages are typically encoded in UTF-8, but other extended ASCII encodings and codepages are also supported. This includes ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
• Repositories created on such [non UTF-8] systems will not work properly on UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.
• Line endings can be LF, CRLF, or any native system line ending. Line endings can change per-file or be across an entire repository.

Today with WSLgit v0.50, data that is not UTF-8 is already being corrupted by WSLgit. Several charsets like ASCII, Windows-1251, and ISO-8859-1 have the same bytes encoding for commonly use characters. When WSL, git settings, and the user's Windows character set are within this limited set of charsets, it is likely they do not experience corruption. This is the often seen scenario where almost all the characters are ok except for the occassional ü or Ó doesn't look correct.

This leads me to some recommendations:

1. I do not recommend WSLgit have comprehensive character-set support. Why? Because git itself has some limitations as written above. And, WSLgit is not a tool that needs to solve all problems.
2. One of these problems to not fix is line endings. Line endings are not just LF and CRLF. However, since Git has some limitations on this and we don't have to solve all problems... I recommend only supporting LF and CRLF. References: https://en.wikipedia.org/wiki/Newline and https://docs.microsoft.com/en-us/visualstudio/ide/encodings-and-line-breaks
3. Do not use conversion or validation APIs like from_utf8_lossy() or from_utf8(). These APIs will corrupt data that is not valid UTF-8. Instead, transparently accept all data with APIs like from_utf8_unchecked() or leave them in byte buffers. This is ok. Why? Because there are two cases today:
   1. UTF-8 data -- this data works today and will continue to work with the unchecked APIs because it is already valid UTF-8. A side benefit is the unchecked APIs will be faster because it doesn't need to validate anything since the data is already valid UTF-8.
   2. not UTF-8 data -- this data is already being corrupted today. Therefore, it can only get better. By using the unchecked APIs, it is possible for the data to still be workable/usable. All of this data is just bits in groups of bytes. The bytes should not change. For commands like git show this is essential -- the data must not be altered in any way. For commands like git rev-parse the data might still work since the byte values can be transparently passed-through and as they are captured by tools like VS Code, they may correctly use the user's alternate character set since the bytes were transparently passed to them. Yes, there might be a problem if the data uses a path with non UTF-8 data in it and one or more of the /\:mnt characters have a different byte encoding. However, this is no worse than today's already corruption of that same data. And it might be better if those 6 characters are encoded with the same bytes because the other characters may be transparently passed-through.

I have code which uses the above recommendations at https://github.com/diablodale/wslgit/tree/charset_trans

Even if I make ssh-agent running inside WSL before invoking wslgit, there is no way to use ssh-agent info from wslgit.

It would be nice I can use existing SSH_AUTH_SOCK inside WSL.

Just installed the latest insider build 18970 with Ubuntu 18.04 on WSL2 with .zsh and running wslgit.exe from PowerShell just opens a new bash session. Please see screenshot below

Edit: tried to set Windows environment WSLGIT_USE_INTERACTIVE_SHELL variable to 0 and it didn't works the same way

When I tried to run install.bat it throws this error...

Make sure Fork.RI is executable in WSL...
ERROR! Failed to make Fork.RI executable in WSL.

$ ls -al  /c/Program\ Files/wslgit/cmd/
total 1400
dr-xr-xr-x 1 hassansiddique hassansiddique     512 Jun 28 23:19 .
dr-xr-xr-x 1 hassansiddique hassansiddique     512 Jun 28 23:19 ..
-rwxrwxrwx 1 hassansiddique hassansiddique    1411 Jun 28 23:19 Fork.RI
-r-xr--r-- 1 hassansiddique hassansiddique 1428480 Jun 28 23:19 wslgit.exe

I'm using Pengwin (Debian) on WSL2.

Hi,

This is a PR for #97,

I've cleaned up the changes I do for the Fork patch, separating it in its own file to keep main.rs as clean as possible. I understand if you think that this is out of scope for the wslgit project, if so then maybe the other commits in this PR can be interesting on their own.

• The first two and the fourth commit (82645f3, 3997e63 and 264ffdf) are just some refactoring to make adding the patch cleaner. (If you decide to not accept this PR I would be really glad if you at least took these three commits.)
• The third commit (3254818) adds a script to package a release in a zip-file containing the following structure:

  ├── wslgit
  │   ├── bin
  │   │   └── wslgit.exe
  │   └── install.bat
  

  The install.bat script must be run as administrator and creates three symbolic links in the wslgit\bin folder, mimicing the bin folder in a Git for Windows installation since it is needed by one of the tools I use:

  git.exe -> wslgit.exe
  bash.exe -> C:\Windows\System32\bash.exe
  sh.exe -> C:\Windows\System32\bash.exe
  

• The fifth commit (f908e7a) is the patch for Fork.

(If you decide to accept this PR then might I suggest that you create a develop-branch first and merge this PR into that branch instead of the master, since I have updated the README which would make the instructions not compatible with the latest release.)

I use fish as my exclusive shell in wsl, and have a variety of variables and functions set in config.fish that I frequently use in my git usage.

I would very much like not to have to port these over to bash, as they are in some cases impossible to port, so I was wondering if an option to use the default shell (set by chsh) or to set a specific shell could be added?

When I implemented #129 I did some simple performance measurements and I thought I'd share the results.

Test Results

WSL2 Filesystem

Clone from WSL2 to WSL2 filesystem:

| git | clone time | |----|------| | wsl2 | 0.580s | | wslgit-wsl2 | 0.786s |

(I also ran this test on my work laptop that is ~8 years newer than my private desktop and the measured times were 0.404s and 0.455s, so on modern hardware the wslgit overhead is even lower)

Windows Filesystem

Clone from Windows filesystem to Windows filesystem:

| git | clone time | |----|------| | win64 | 5.769s | | wsl1 | 11.837s | | wslgit-wsl1 | 11.800s | | wsl2 | 63.448s | | wslgit-wsl2 | 63.879s |

(Unfortunately I cannot disable the antivirus on my work-laptop so it is actually slower than my old desktop)

Anitvirus

The AV can have a huge impact on the git performance. On my desktop I use Microsoft Defender Antivirus where it is possible to exclude folders and processes. I ran this test using git from my WSL1 instance (Alpine Linux) and tried combinations of disabling then folder and the processes. The nice thing about WSL1 is that the processes are actually visible by Windows so it is possible to add WSL1 processes to the exclusion list, for Alpine Linux the processes to exclude are busybox and git.

| exclusion | clone time | |----|------| | - | 48.708s | | Processes (busybox+git) | 11.689s | | Folder | 12.981s | | Folder + Processes | 11.577s |

The results indicate that it is actually better to exclude the processes rather than the folder.

Test Method

I first cloned the microsoft/vscode repository to the local disk and then measured the time it took to clone from the local copy to a destination on the same filesystem (Win->Win, and WSL2->WSL2) using wslgit, git for windows (64-bit), and git inside WSL1 and WSL2.

When running wslgit on the Windows filesystem the WSL-distro to use was selected using the new WSLGIT_DEFAULT_DIST variable by using the following PowerShell command:

$env:WSLGIT_DEFAULT_DIST="MyWSL1Dist"

From a bash-shell in WSL1/WSL2 I used the time command and in PowerShell I used the Measure-Command to measure the time:

Measure-Command { wslgit clone vscode vscode-1 }

time git clone vscode vscode-1

Don't forget to delete vscode-1 before running again.

In Sourcetree v3.3.9, right-click on a commit and click Rebase children of xxxxx interactively...

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks -c sequence.editor='C:\Users\dhanar_accelbyte\AppData\Local\SourceTree\app-3.3.9\tools\stree_gri' -c core.editor='C:\Users\dhanar_accelbyte\AppData\Local\SourceTree\app-3.3.9\tools\stree_gri' rebase -i --autosquash ade5bf53e5a5c014889bb30820bb1da4c04e7300
C:\Users\dhanar_accelbyte\AppData\Local\SourceTree\app-3.3.9\tools\stree_gri: 1: C:Usersdhanar_accelbyteAppDataLocalSourceTreeapp-3.3.9toolsstree_gri: not found
error: There was a problem with the editor 'C:\Users\dhanar_accelbyte\AppData\Local\SourceTree\app-3.3.9\tools\stree_gri'.
Completed with errors, see above.

It seems like C:\Users\dhanar_accelbyte\AppData\Local\SourceTree\app-3.3.9\tools\stree_gri is translated to C:Usersdhanar_accelbyteAppDataLocalSourceTreeapp-3.3.9toolsstree_gri

Workaround in WSL2 to avoid this problem:

cd /usr/local/bin
sudo ln -s /mnt/c/Users/dhanar_accelbyte/AppData/Local/SourceTree/app-3.3.9/tools/stree_gri.exe C:Usersdhanar_accelbyteAppDataLocalSourceTreeapp-3.3.9toolsstree_gri

I'm getting the following error whilst trying an interactive rebase/Squashing:

/mnt/c/Users/Name Surname/Downloads/wslgit/wslgit/bin/Fork.RI: 1: /mnt/c/Users/Name: not found

error: There was a problem with the editor '/mnt/c/Users/Name Surname/Downloads/wslgit/wslgit/bin/Fork.RI'.

Every other actions are working fine.

I suspect there's a problem with the space in the path.

I used the install.bat with a successful installation and placed the wslgit.exe somewhere on my machine and added it to PATH.

However when I try to set a custom git instance in Fork it doesn't appear to change?

EDIT - Ah am a little stupid, didn't notice the symlinks were 0 bytes? Maybe the setup is sort of unclear to me?

I installed newest wslgit release and add it to PATH.

wsl1: Ubuntu 18.04LTS git version in wsl1 : git version 2.17.1

wslgit /bin/bash: - : invalid option