Use Git installed in Bash on Windows/Windows Subsystem for Linux (WSL) from Windows and Visual Studio Code (VSCode)

Overview

WSLGit

This project provides a small executable that forwards all arguments to git running inside Bash on Windows/Windows Subsystem for Linux (WSL).

The primary reason for this tool is to make the Git plugin in Visual Studio Code (VSCode) work with the git command installed in WSL. For these two to interoperate, this tool translates paths between the Windows (C:\Foo\Bar) and Linux (/mnt/c/Foo/Bar) representations.

Installation

The latest binary release can be downloaded from the releases page.

[Optional 1] Run the install.bat script as administrator.
The install.bat script creates a folder structure similar to the one used by Git For Windows, and creates some useful symbolic links in the wslgit\cmd and wslgit\bin folders.

[Optional 2] Add the wslgit\cmd directory to your Windows Path environment variable (user or system).
To change the environment variable, type Edit environment variables for your account into Start menu/Windows search and use that tool to edit Path.

You may also need to install the latest Microsoft Visual C++ Redistributable for Visual Studio 2017.

Usage in VSCode

VSCode will find the git executable automatically if the two optional installation steps were taken.

If not, set the appropriate path in your VSCode settings.json:

{
    "git.path": "C:\\CHANGE\\TO\\PATH\\TO\\wslgit\\cmd\\wslgit.exe"
}

Also make sure that you use an SSH key without password to access your git repositories, or that your SSH key is added to a SSH agent running within WSL before starting VSCode. You cannot enter your passphrase in VSCode!

If you use a SSH agent, make sure that it does not print any text (like e.g. Agent pid 123) during startup of an interactive bash shell. If there is any additional output when your bash shell starts, the VSCode Git plugin cannot correctly parse the output.

Usage from the command line

If you did the two optional installation steps then you can then just run any git command from a Windows console by running wslgit COMMAND or git COMMAND and it uses the Git version installed in WSL.

Usage in Fork

To make Fork use git from WSL you must have done the first optional installation step (run install.bat). Then go to the Fork preferences and select a custom git instance where you point it to the git.exe in the wslgit\bin folder (not the cmd folder!).

Remarks

Currently, the path translation and shell escaping is very limited, just enough to make it work in VSCode.

All absolute paths are translated, but relative paths are only translated if they point to existing files or directories. Otherwise it would be impossible to detect if an argument is a relative path or just some other string. VSCode always uses forward slashes for relative paths, so no translation is necessary in this case.

Additionally, be careful with special characters interpreted by the shell. Only spaces and newlines in arguments are currently handled.

Advanced Usage

WSLGIT_USE_INTERACTIVE_SHELL

To automatically support the common case where ssh-agent or similar tools are setup by .bashrc in interactive mode then, per default, wslgit executes git inside the WSL environment through bash started in interactive mode for some commands (clone, fetch, pull and push), and bash started in non-interactive mode for all other commands.

The behavior can be selected by setting an environment variable in Windows named WSLGIT_USE_INTERACTIVE_SHELL to one of the following values:

  • false or 0 - Force wslgit to always start in non-interactive mode.
  • true, 1, or empty value - Force wslgit to always start in interactive mode.
  • smart (default) - Interactive mode for clone, fetch, pull, push, non-interactive mode for all other commands. This is the default if the variable is not set.

Alternatively, if WSLGIT_USE_INTERACTIVE_SHELL is not set but the Windows environment variable BASH_ENV is set to a bash startup script and the environment variable WSLENV contains the string "BASH_ENV", then wslgit assumes that the forced startup script from BASH_ENV contains everything you need, and therefore also starts bash in non-interactive mode.

This feature is only available in Windows 10 builds 17063 and later.

WSLGIT

wslgit set a variable called WSLGIT to 1 and shares it to WSL. This variable can be used in .bashrc to determine if WSL was invoked by wslgit, and for example if set then just do the absolute minimum of initialization needed for git to function.
Combined with WSLGIT_USE_INTERACTIVE_SHELL=smart (default) this can make every git command execute with as little overhead as possible.

This feature is only available in Windows 10 builds 17063 and later.

Building from source

First, install Rust from https://www.rust-lang.org. Rust on Windows also requires Visual Studio or the Visual C++ Build Tools for linking.

The final executable can then be build by running

cargo build --release

inside the root directory of this project. The resulting binary will be located in ./target/release/.

Tests must be run using one test thread because of race conditions when changing environment variables:

# Run all tests
cargo test -- --test-threads=1
# Run only unit tests
cargo test test -- --test-threads=1
# Run only integration tests
cargo test integration -- --test-threads=1
# Run benchmarks (requires nightly toolchain!)
cargo +nightly bench
Comments
  • Can't use wslgit.exe with SmartGit 18

    Can't use wslgit.exe with SmartGit 18

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

    image

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

    image

    Am I doing something wrong?

    enhancement needs feedback 
    opened by rfgamaral 29
  • VSCode 1.18.1 and wslgit

    VSCode 1.18.1 and wslgit

    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?

    bug needs feedback 
    opened by riula 20
  • Use wslpath for Insider Builds 17063 and later

    Use wslpath for Insider Builds 17063 and later

    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/

    enhancement 
    opened by Plailect 19
  • Issue with bash not showing the commit details in Fork

    Issue with bash not showing the commit details in Fork

    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.

    image

    I'm using Fork Version 1.80

    Hope you can help me,

    Thanks

    opened by andROYdified 18
  • WSLGit doesn't work

    WSLGit doesn't work

    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)

    opened by nicholasio 16
  • Error:

    Error: "The application was unable to start correctly (0xc000007b)"

    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.

    help wanted 
    opened by aalaap 13
  • data can be corrupted by wslgit assuming everything is utf-8

    data can be corrupted by wslgit assuming everything is utf-8

    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

    opened by diablodale 13
  • Allow using ssh-agent inside WSL from wslgit

    Allow using ssh-agent inside WSL from wslgit

    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.

    enhancement 
    opened by rigarash 13
  • Doesn't work with WSL2

    Doesn't work with WSL2

    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 image

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

    opened by anpin 12
  • Can't run install.bat

    Can't run install.bat

    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.

    opened by HassanSiddique 11
  • Fork patch cleanup 2

    Fork patch cleanup 2

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

    opened by carlolars 11
  • Fish (and other shells) support

    Fish (and other shells) support

    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?

    opened by Zopolis4 2
  • Performance Measurements

    Performance Measurements

    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.

    opened by carlolars 1
  • Interactive Rebase/Commit Squashing not working inside Sourcetree

    Interactive Rebase/Commit Squashing not working inside Sourcetree

    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
    
    opened by dhanar10 0
  • Interactive Rebase/Commit Squashing not working inside Fork

    Interactive Rebase/Commit Squashing not working inside Fork

    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.

    opened by ffornazaric 2
  • Git fork selecting custom git instance doesn't change

    Git fork selecting custom git instance doesn't change

    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?

    image

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

    opened by efsjouw 3
  • invalid option error with WSL1

    invalid option error with WSL1

    I installed newest wslgit release and add it to PATH.

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

    image

    wslgit /bin/bash: - : invalid option

    needs feedback 
    opened by xiaok 1
Releases(v1.2.0)
  • v1.2.0(Dec 30, 2022)

  • v1.1.1(Mar 22, 2022)

  • v1.1.0(Mar 13, 2022)

  • v1.0.1(Aug 25, 2020)

    The 1.0.1 update is a re-release of v1.0.0 which fixes a bug in the new install script (#110), it is otherwise identical to version 1.0.0.

    This release improves compatibility with other tools. In the ZIP download, an install script is provided to create a directory structure similar to Git for Windows, allowing many tools to auto-detect wslgit. Further, a proxy script to improve compatiblity with the Fork client is provided.

    Detailed changelog:

    Added

    • Add install script to create binaries and directory structure similar to Git for Windows. This enables tools to auto-detect Git, if the created directory is added to the Windows Path.
    • Add proxy to call Fork.RI from WSL.

    Changed

    • Add ls-remote to commands that use an interactive bash shell (#101).
    • Treat file arguments after -- as relative paths (#102).
    • Include version number in logging output (#105).
    • Invoke wsl without default shell (#107).

    Fixed

    • Fix translation of URLs that start with a transport protocol (#103).
    Source code(tar.gz)
    Source code(zip)
    wslgit.exe(1.36 MB)
    wslgit.zip(493.73 KB)
  • v1.0.0(Aug 22, 2020)

    This release improves compatibility with other tools. In the ZIP download, an install script is provided to create a directory structure similar to Git for Windows, allowing many tools to auto-detect wslgit. Further, a proxy script to improve compatiblity with the Fork client is provided.

    Detailed changelog:

    Added

    • Add install script to create binaries and directory structure similar to Git for Windows. This enables tools to auto-detect Git, if the created directory is added to the Windows Path.
    • Add proxy to call Fork.RI from WSL.

    Changed

    • Add ls-remote to commands that use an interactive bash shell (#101).
    • Treat file arguments after -- as relative paths (#102).
    • Include version number in logging output (#105).
    • Invoke wsl without default shell (#107).

    Fixed

    • Fix translation of URLs that start with a transport protocol (#103).
    Source code(tar.gz)
    Source code(zip)
    wslgit.exe(1.36 MB)
    wslgit.zip(493.70 KB)
  • v0.9.0(Jan 10, 2020)

    This release changes translation of paths between Windows and WSL. All paths are now translated by the wslpath utility. This enables the use of custom mount roots without any additional configuration for wslgit (i.e. drive mounts like /c work out of the box now).

    There is also a new smarter default for when to use an interactive shell. This removes the need to set any environment variables for most users of wslgit.

    Detailed changelog:

    Added

    • New WSLGIT environment variable that is set to 1 by wslgit and shared to the WSL environment.

    Changed

    • Use wslpath to translate paths between Windows and Linux (#12, #71).
    • New default smart for WSLGIT_USE_INTERACTIVE_SHELL - only uses an interactive bash shell for clone, fetch, pull and push.

    Removed

    • Remove WSLGIT_MOUNT_ROOT environment variable, this is handled by wslpath now.
    Source code(tar.gz)
    Source code(zip)
    wslgit.exe(1.31 MB)
  • v0.8.0(Oct 11, 2019)

    This version fixes several issues and supports custom mount roots via a new environment variable, thanks to @carlolars.

    Important: Users of wslgit-mount-at-root.exe 0.7.0 need to set the new Windows environment variable WSLGIT_MOUNT_ROOT to /.

    Added

    • New environment variable WSLGIT_MOUNT_ROOT to configure the WSL mount root (#78).

    Fixed

    • Improve shell escaping of invalid characters (#27, #54, #73), fixed by #74 and #76.
    • Support flags for BASH_ENV in WSLENV environment variable (#56), fixed by #78.
    • Fixed translating to windows path from the root of a mounted drive (#80).
    • Support empty command line arguments (#84).

    Changed

    • Format code using rustfmt.
    • Unify interactive/non-interactive configurations, both use bash -c now.
    • Expand tests and add integration tests (#76).
    • WSLGIT_USE_INTERACTIVE_SHELL now has higher priority than a BASH_ENV/WSLENV configuration (#78).
    Source code(tar.gz)
    Source code(zip)
    wslgit.exe(1.33 MB)
  • v0.7.0(Jan 24, 2019)

    This release contains fixes to several corner cases.

    Additionally, a new experimental build is provided for configurations where drives are mounted directly at / (i.e /c instead of /mnt/c) - see #42. Use the wslgit-mount-at-root.exe binary for this case.

    Added

    • Support for relative paths as arguments. (partial fix for #37)
    • Translate paths in long form arguments, e.g. --file=C:\some\path (partial fix for #37)

    Fixed

    • Support git commands in any argument position when deciding wether to translate paths in the output of the command. (#47)
    • Fix incorrectly quoted arguments with spaces in non-interactive setup. (#46)

    Changed

    • To support manually mounted network drives, the working directory inside WSL is now explicitly changed to the current working directory of wslgit in Windows. (#50)
    Source code(tar.gz)
    Source code(zip)
    wslgit-mount-at-root.exe(1.16 MB)
    wslgit.exe(1.16 MB)
  • v0.6.0(Apr 24, 2018)

    This is a larger release with several fixes and internal changes.

    Added

    • Allow running bash in non-interactive mode for improved performance (#16, #23).

    Fixed

    • Unix paths inside file contents are not being erroneously translated anymore (#19).
    • Do not assume valid UTF-8 output from git (#29).
    • Fix running wslgit without arguments (#26).
    • Escape \n newlines in arguments to git (#27).

    Changed

    • Change to wsl.exe to call into the WSL environment.
    • Apply path translation only to output of rev-parse and remote.
    Source code(tar.gz)
    Source code(zip)
    wslgit.exe(1.13 MB)
  • v0.5.0(Jan 11, 2018)

  • v0.4.0(Dec 18, 2017)

  • v0.3.0(Nov 8, 2017)

  • v0.2.0(Jul 27, 2017)

Owner
A. R. S.
A. R. S.
A visual studio code's workspaces organizer written in Rust

ruscode A visual studio code's workspaces organizer written in Rust Supports Linux, and Windows. What is a workspaces organizer? After months of or ev

晧暐 8 Dec 15, 2022
A CLI utility installed as "ansi" to quickly get ANSI escape sequences. Supports the most basic ones, like colors and styles as bold or italic.

'ansi' - a CLI utility to quickly get ANSI escape codes This Rust project called ansi-escape-sequences-cli provides an executable called ansi which ca

Philipp Schuster 5 Jul 28, 2022
A cargo subcommand for checking and applying updates to installed executables

cargo-update A cargo subcommand for checking and applying updates to installed executables Documentation Manpage Installation Firstly, ensure you have

наб 827 Jan 4, 2023
A CLI tool that allow you to create a temporary new rust project using cargo with already installed dependencies

cargo-temp A CLI tool that allow you to create a new rust project in a temporary directory with already installed dependencies. Install Requires Rust

Yohan Boogaert 61 Oct 31, 2022
A Rust CLI tool that helps you enforce Git policies through Git hooks both server and client side

GitPolicyEnforcer This is a command line utility written in Rust, that helps you utilize Git hooks, to enforce various policies. It currently supports

Vagelis Prokopiou 4 Aug 14, 2022
🗄️ A simple (and safe!) to consume history of Client and Studio deployment versions.

??️ Roblox Version Archive A simple (and safe!) to consume history of Client and Studio deployment versions. About Parsing Roblox's DeployHistory form

Brooke Rhodes 4 Dec 28, 2022
git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers.⛰️

git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Orhun Parmaksız 5k Jan 9, 2023
A git sub-command to view your git repository in the web browser

git-view A git sub-command to view your git repository in the web browser! About Are you also frustrated from moving your hands away from the keyboard

Hamothy 5 Sep 26, 2022
Git Explorer: cross-platform git workflow improvement tool inspired by Magit

Gex Git workflow improvement CLI tool inspired by Magit. This project is still under initial development, but I am actively dogfooding it and features

Peter Hebden 204 Jan 6, 2023
Bashly - Bash CLI Framework and Generator

Bashly - Bash CLI Framework and Generator Create feature-rich bash scripts using simple YAML configuration

Danny Ben Shitrit 1.4k Jan 4, 2023
A `nix` and `nix-shell` wrapper for shells other than `bash`

nix-your-shell A nix and nix-shell wrapper for shells other than bash. nix develop and nix-shell use bash as the default shell, so nix-your-shell prin

Mercury 15 Apr 10, 2023
CLI program for sending one-off requests to the VTube Studio API

vtubestudio-cli (vts) CLI program for sending one-off requests to the VTube Studio API. It connects to the websocket, authenticates, performs one or t

null 2 Nov 24, 2021
Nvm - Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Node Version Manager Table of Contents Intro About Installing and Updating Install & Update Script Additional Notes Troubleshooting on Linux Troublesh

nvm.sh 63.8k Jan 7, 2023
A handy way to handle sh/bash cli parameters

Argc A handy way to handle sh/bash cli parameters. How Argc works To write a command line program with Argc, we only need to do two things: Describe t

null 398 Jan 3, 2023
An enhanced history(1) for bash

history This is a replacement for the history builtin in bash. It has a couple of additional features that relative to the one included with bash: Con

Robert T. McGibbon 4 Aug 25, 2022
GPT-3 powered CLI tool to help you remember bash commands.

Rusty: GPT-3 Powered CLI Tool Convert natural language into executable commands directly from the terminal! Open source CLI tool powered by OpenAI (br

Zahid Khawaja 287 Apr 19, 2023
A visual canvas and virtual machine for writing assembly to build cool things. Create machines and connect them together.

Visual Assembly Canvas A highly visual assembly editor, infinite canvas for wiring blocks and machines together, bytecode virtual machine runnable nat

Phoomparin Mano 31 Oct 11, 2023
A visual canvas and virtual machine for writing assembly to build cool things. Create machines and connect them together.

Visual Assembly Canvas A highly visual assembly editor, infinite canvas for wiring blocks and machines together, bytecode virtual machine runnable nat

Phoomparin Mano 32 Oct 11, 2023
TMM is a Linux native game modding tool. it allows to install and depoly mods for Linux native and wine games.

Tux Mod Manager TMM is a Linux native mod manager made with the Tauri toolkit. It can install, load, remove and deploy mods for both Linux native and

Mathiew May 119 Dec 27, 2022