gitbutler
gitbutler copied to clipboard
gitbutlerapp
Windows support
Really looking forward trying this out on my win machine! Any chance this would run on WSL in the meantime?
@francois-joubert It seems to run on my WSL instance but has DPI scaling issues that makes it unusable:
@anaisbetts What kind of monitor do you have? On my Dell XPS 17 monitor it looks fine.
The only problem is that the login does not work, I don't know if that has to do with it running in WSL.
I installed firefox on my wsl instance and set it as my default browser using microsoft RDP to get into the settings app for the wsl instance (basic instructions for connecting via rdp here). Once I had a working default browser setup, I was able to complete the sign in process and have all features working via wsl.
I have created a gist that provides a complete walkthrough for getting GitButler working on WSL: https://gist.github.com/KroniK907/24c6edafa2b34af773dc9466dd7e4e00
I have reduced the steps as much as possible, and provided instructions for installing both the AppImage version as well as the .deb version. The deb version takes 4 terminal commands and less than 2 minutes to get running, and while the AppImage version requires a little bit more effort to set up, allows for the app to update itself, rather than requiring a manual .deb install for each new release.
Important note: this solution is really only practical if you are willing to set up your dev environment in WSL. Trying to make the WSL gitbutler instance interact with a project stored on the windows filesystem can be laggy or not work at all if it's a big enough project.
@KroniK907 Thank you, this was way faster than my way which was compiling it from scratch. Though it is still very unstable for me.
But I'll keep trying to see if I can fix my issues
Edit: After restarting git-butler a couple of time it worked fine
Another windows user praying for win support, Unreal Engine dev not a great experience on linux, WSL is abit much effort as well
@GIRU-GIRU I got GitButler setup on WSL in a matter of minutes. (I did already have WSL setup)
I used this guide by @KroniK907
I have created a gist that provides a complete walkthrough for getting GitButler working on WSL: https://gist.github.com/KroniK907/24c6edafa2b34af773dc9466dd7e4e00
Looks like according to a comment on my gist that the WSL solution is really only viable if you are hosting your repos in WSL, otherwise the lag of having WSL access the windows file system makes it rather laggy and hard to use at best, and completely times out and is not useable at worst.
However, if you are able to use WSL as your dev environment it works really nicely.
Updated my gist to add instructions for installing GitButler as an AppImage. The main reason for adding the AppImage install instructions was because the AppImage version can update itself, while the .deb has to be manually updated for each release.
Because the team is adding improvements and releasing new updates quickly, it seemed practical to provide install instructions for a version that did not require as much effort to keep up to date.
I have and use WSL but my repos are windows only (WPF) looking forward for windows support
I have a setup where GUI apps from WSL run via VcXSrv on Windows side, one issue I encountered:
The window appears, but it is empty, and terminal shows no errors, or this error:
[...] 'GLXBadFBConfig'.
(Details: serial 172 error_code 163 request_code 149 (GLX) minor_code 21) [...]
These changes helped me solve the issue:
disable the wgl setting in vcxsrv, and also remove LIBGL_ALWAYS_INDIRECT from my linux environment
When Windows is supported, will it have support for the WSL filesystem? I feel like installing gitbutler in WSL isn't the best solution for WSL devs.
I feel like installing gitbutler in WSL isn't the best solution for WSL devs.
As a wsl dev, installing GitButler in WSL has been working great for me. But to your question about file access, any windows app can access the \\wsl.localhost\ network path to the wsl instances. But that may end up being kinda laggy. We won't know for sure what that performance hit will look like till there is a windows build.
Would love to help get this running natively on Windows, what's currently blocking this?
Native Windows dev so happy to help here!
Would love to help get this running natively on Windows, what's currently blocking this?
Native Windows dev so happy to help here!
https://github.com/Byron/gitoxide/issues/1287 mentions this issue and has a few things to attack
Would love to help get this running natively on Windows, what's currently blocking this? Native Windows dev so happy to help here!
Byron/gitoxide#1287 mentions this issue and has a few things to attack
Which says about Windows support:
There may be rough edges around program and hook invocations, to be smoothed out of time (probably this is about more than Git though, currently unclear)
Which sounds to me like the thing to pick up here is getting a beta (alpha?) Windows build done, and letting people test it? Then we can find said "rough edges", make tickets for them and get them fixed.
And a second mention about Windows support:
On Windows, there is no native ssh transport yet which might be worse than git2 right now.
Git for Windows comes with the option to install ssh (if I recall correctly) and modern Windows versions might even support it out of the box. At least, my Windows dev box runs all git commands over ssh and also uses it for signing commits. A simple check to see if ssh is in $PATH should be enough right? Especially for a beta.
Modern Windows installations will have ssh installed and available as an .exe and I think a link library too.
The git for windows depends on the install, for example I only install Git itself without any of the extras (I don't want their weird bundled terminal emulator and linuxy libraries, I just want git.exe - so I opt for installing only that, which may omit the ssh installs too since I never use ssh anyway) so a check to see if it's in Path like on any other system would make the most sense along with a helpful error message if not, linking to the relevant install docs.
Is there any way SSH could just be packaged with the install in future, either via static linking or a DLL?
Is there any way SSH could just be packaged with the install in future, either via static linking or a DLL?
One of the nice features of using SSH is the option for key based authentication and using ssh-agent. You can then add and remove auth and signing keys to ssh-agent on the fly (eg. with a password manager). I think this all falls apart if apps start using different SSH libraries, since a specific ssh-agent seems to be linked to its specific ssh instance. At least, that is my experience while fighting ssh key auth on a box having SSH bundled with Git, SSH bundled with Windows and an OpenSSH install side by side.
Anyway, the "no native ssh transport yet" seems clear enough and solvable (take ssh from path). I'm more interested in the "There may be rough edges around program and hook invocations" bit.
PS. According to some Microsoft blogs, SSH is available as a Windows Feature for general public from Windows 10 version 1803 (released early 2018) onwards.
PS. According to some Microsoft blogs, SSH is available as a Windows Feature for general public from Windows 10 version 1803 (released early 2018) onwards.
That's right! It's trivial to install or check if it's available and installed with DISM or its equivalent Powershell commands, it's as simple as Add-WindowsCapability -Online -Name OpenSSH.Client* (the name includes a version number, hence the trailing wildcard). And if you ask me, Windows Server 2019 or Windows 10 (build 1809, not 1803) is entirely fine to have as a minimum requirement.
But wait, there's more! Microsoft is working on an updated version on GitHub, and ship beta versions which can be installed with winget (literally just winget install "openssh beta"!) or downloaded as a .zip or .msi from their GitHub releases (and can therefore also be packaged and shipped with GitButler if desired).
Hope that helps!
Just pushed a small fix that should unlock project creation on Windows in cases where it might have failed before. There are other issues (performance being a big one). There are other issues I'm investigating at the moment, however I'd love to know which ones people are running into still. Builds should be un-broken, too.
mkdir gitbutler-ui/build
cargo build
pnpm i
pnpm tauri dev
Feel free to comment here.
ok so some things i have noticed:
-
when fetching from origin/main on trunk even though it has completed the task according to the terminal output, it is stuck on
busy.... -
when clicking on Trunk to view commits on the branch the images seem to be broken.
-
gitbutler seems to be reporting changes incorrectly saying i have 69 changes when i have 3 modifications and 3 unwatched files.
-
unable to create a new branch / dragging dropping files does not work.
I'll keep using it and update if i find anything else.
- when fetching from origin/main on trunk even though it has completed the task according to the terminal output, it is stuck on
busy....
I experienced this as well, and I noticed in the DevTools window when this happened I eventually received the error: "Project [GUID] does not have a default target set" even though during setup I selected origin/main as the base branch and the UI reflected that as well.
when fetching from origin/main on trunk even though it has completed the task according to the terminal output, it is stuck on busy....
I think this is a known issue that affects all versions. Definitely will get addressed at some point.
when clicking on Trunk to view commits on the branch the images seem to be broken.
You mean e.g. profile picture images? Or do you mean something else?
gitbutler seems to be reporting changes incorrectly saying i have 69 changes when i have 3 modifications and 3 unwatched files.
Yeah I faced this too, was this a repo you had cloned from WSL by chance, and are accessing via the Windows side of things? Either via /mnt or the other direction, from Windows -> WSL via the network share? Or was this Windows through and through?
I noticed it on an otherwise 'clean' (no unstaged/staged changes, clean working directory) repository, and git status was reporting mode changes after opening it with GB, which doesn't surprise me at all.
unable to create a new branch / dragging dropping files does not work.
Yeah, confirmed this on my end as well. Will look into it.
I experienced this as well, and I noticed in the DevTools window when this happened I eventually received the error: "Project [GUID] does not have a default target set" even though during setup I selected origin/main as the base branch and the UI reflected that as well.
This might be a timing/performance thing, at least on my end you could at least get into the virtual branch view and see one branch (but couldn't create any others). Unless I'm misunderstanding what you're saying.
Thanks for testing things!
When running commit 7eabc10 in dev mode my virtual branch with about 5 files (1 of them is a LFS binary file) is generating a new name every second. I do want to mention performance wise it's (obviously) running much faster natively then working on the Windows file system from WSL2
