Reasonably, I believe this to be the best TUI for git I’ve yet to find. The features and straightforward nature of its operation make it a joy to use, and a very useful addition to my toolbox. Could it be slightly more customizable for my workflow? Maybe. But I adore it all the same and find it indispensable. These new additions and enhancements only serve to further distinguish it.
I’m not not running brew update && brew upgrade on my systems right now like a madman.
I’ve also basically switched to it, but one thing does annoy me: it seems to eat control-z so I can’t background it. I presume this was done for a reason (someone had to write the code to do it) and I’m curious what the motivation was.
Yay! Now if only I could work out why selecting multiple lines doesn’t work in macOS for me. The tool is largely useless without that (so frustrating to stage lines one at a time) but it looks like it doesn’t affect people other than me.
Sorry to hear that this makes it useless for you. Feel free to add more info to reproduce the problem in the GitHub issue. So far it seems you are the only user with that problem
I’m really stuck: I haven’t got any custom settings in my terminal, I don’t think I have anything weird in my environment, I’m using the version from homebrew so not even building my own version with a potentially-broken toolchain. Yet holding shift while pressing arrow keys acts as if shift is not held. If there’s anywhere I can stick debugging logs and build it myself, let me know. I was using gitui a lot on my Windows laptop, but I gave that machine back when I resigned so can’t reproduce the environment where it worked for me anymore.
Yeah, thank YOU! I guess I need to spend some time learning how to configure things better and such. It’s on me to become a power user, expert operator, competent enthusiast, etc.
Well there are probably a lot like you, so please consider making this a blog post, video or something - we will gladly share this on the project page :)
I’ve been looking for good cross-platform FOSS alternatives to GitHub tools or VS Code for pretty git interfaces, and gitui is the winner for me so far. It’s definitely made it easier for me to manage git repos even with its incomplete feature set, and as this release demonstrates it is quickly gaining functionality, making it even more pleasant to use.
I will mention a specific pain point for me: gitui supports creating tags and pushing tags, but it doesn’t appear to support annotating tags. For git commits it supports opening the commit message in your editor if you want to write more than one line, why not do something similar for annotating tags?
i don’t know if you’ve tried magit but it is hands down the most phenomenal way to use git in my opinion. downside is that you have to use emacs but you could probably tie it to a pared down version of it which i might just try to get going this weekend. despite it being tied to emacs it’s well worth the time to load up and use it. spacemacs has a decently polished layer that includes magit and vim customizations that make it all work well together.
Neither does magit, in fairness, except for the editing of commit messages. And even then, you can use vi keybindings.
I intend no snark by pointing this out; I have colleagues who used other editors and only touched Emacs for magit.
That said, it’s great to see a good GUI for Emacs building momentum. I’ve seen so many new and junior Devs utterly confused by Git. (This is in part to do with how it’s usually taught, but also that the CLI is IMO quite confusing to learn).
I’m really rooting for this project. Currently I’m relying on VS Code as a GUI for a lot of my git workflow, which at least isn’t reliant on GitHub and can work with other code forges like SourceHut, but it’s still ultimately a Microsoft product and an Electron app I’d rather not require. I’m hoping gitui can make GUIs unnecessary for me.
I’m also slowly familiarizing myself with other tools like https://github.com/dandavison/delta and trying to get better with git commands on the command line, rather than using GUIs when I don’t have to.
You could probably achieve similar results using a streaming decoder for JSON, but as with flatbuffer libraries I haven’t seen many around, and I doubt the code would me much more readable than the one using flatbuffers shown in the post.
yeah I wasn’t able to get the streaming decoders for JSON running and the advantage of FB was still that you have random access to at all times into the buffer
This benchmark is pointless and misguided. You are not likely to draw such a large number of lines in your game on a single canvas item, unless you are willingly abandoning benefits that the engine gives you for nearly no gain. All the real work is done by VisualServer, to which the calls are passed. Basically, all this benchmark measures is how fast can the language process sin/cos calls and call other code.
And the tested options have no real difference in performance when tested for realistic conditions! I’ve decreased the number of lines drawn in each test, until the frame rate hit stable V-Sync(60 fps) on my (quite old and GPU limited) Thinkpad. Both GDScript and Rust options hit 600 lines, and only VisualScript lagged behind with 550 lines. The line count tested in the blog post was 10x bigger! 6000 lines is likely more lines than your screen has vertical ones!
But I can say that tweaking with the numbers was a lot easier in GDScript and VisualScript than Rust. In those two I could just change the variable easily in node properties, while for Rust I had to change the code and wait for 4-5 seconds for it to compile.
Always good to start a supposedly objective comment with such a personal note. Thanks for that :)
My intention was to test performance of sending commands between the programming language and the engine api. this is why the amount of lines matters because increasing the load increases the measurability of the performance differences.
Regarding value tweaking: the variables like the amount of lines is exposed as a variable you can tweak exactly like the ones in gdscript so no recompilation required.
I’d love to see the same comparison with C++ and C#. C# is AoT-compiled with Mono, but is still a safe language and so I’d expect it to be slower than C++ or Rust. I’d expect Rust and C++ to be equivalent performance.
I’ve not ever used Godot but it looks sufficiently interesting that I’m hoping to play with it over Christmas. I’d expect to always use GDScript for rapid prototyping and then move to either C# or C++ for anything that turns out to be a bottleneck after profiling and I’m curious about what the perf delta is between C# and Rust or C++ and whether it’s ever worth going all of the way to an unmanaged language.
Given the rest of the thoughtful reply, I think the first sentence is entirely unintentional in its tone.
**edit, I meant to ask, “Are you looking for feedback?” Because there was no submission comment, it is just a link.
I do think you have an opportunity for a second edit of your benchmarking post. I think outlining just how much the number of draw calls is outside of a normal usage and that the other two solutions are totally workable is a good distinction. Benchmarking is hard and in that direction, we need to constantly apply hygienic practices.
I also think it is important to go into the why and how one would measure it. Is it interpreter overhead? Memory allocation? Type checking? Or maybe the Rust code gets inlined, who knows?
One thing I would have like to see is
change the number of loop iterations vs draw calls, what is the loop overhead, the draw call over head
how much allocation is going on inside each loop
how long does it take to get to the loop body
what if we reused the vec inside the loop body, drew the same line over and over again
For bonus points, drawing a flame graph of each run would be amazing.
Two folks I really look up for benchmarking and technical analysis are
Always good to start a supposedly objective comment with such a personal note.
I don’t understand what you mean. I said that this benchmark is pointless and misguided. It is pointless because it is measuring performance of code that is not likely to appear in real game code, therefore failing to provide any meaningful insights. It is misguided because what it is trying to measure is not indicative of real performance you are likely to see if such workload was actually used, as it does not measure the time it takes VisualServer to actually render the lines as the draw commands are queued until it’s time to draw.
My intention was to test performance of sending commands between the programming language and the engine api.
For that to avoid confusing people you should have chosen an example which is obviously doing just that, e.g. using engine’s print function. Currently, if remove the draw_line call, the performance ratios do not change between the languages, which suggests that what this benchmark is actually measuring is how fast can languages calculate sin/cos.
Regarding value tweaking: the variables like the amount of lines is exposed as a variable you can tweak exactly like the ones in gdscript so no recompilation required.
Oh, actually didn’t notice this because Rust has no default struct values, which I was looking for when trying to change the iteration count. Slightly annoying, but it is possible, so I do retract that statement.
I hadn’t heard of lazygit before, a TUI you list as an inspiration. gitui doesn’t have the features I need yet, but it looks like lazygit, which is more mature, does. For example, lazygit handles a lot of interactive rebase cases more smoothly than either my main Git GUI Tower or git rebase. So thanks for the pointer.
They are both awesome and inspired me but either I found them too slow/resource-hungry in some areas or too complicated to use and navigate in others. (maybe a little NIH-syndrome as well).
Can you go into more detail about what problems lazygit has in the “too complicated to use and navigate” category? Have you planned how you will avoid those interface problems in gitui yet?
My vision for gitui is to make it a terminal tool, that is still as easy to learn as a regular GUI. Where I find most alternatives are embracing the ‘I am a terminal tool, expect to be confused by tons of shortcuts and a man page to learn them’-style. I want to have a clean UI that only offers the kind of shortcuts that are applicable in the current situation so that they always fit into a quick-bar on the bottom. simplicity and speed are my motivations. hope that makes any sense :)
For me it was too much of a memory/cpu hog and too slow on big repos. As I am mostly on battery I cannot afford that. Opening lazygit in the linux repo, keeps 1 core busy permanently, fills up to 3 Gig of Ram when scrolling through the commits and grinds to a halt once it parsed all 900k commits.
Love it. You should definitely checkout magit for some UI ideas. It’s superior to everything I’ve used in that sense, and I think anyone that has used it feel the same.
Yup, I don’t really use Emacs these days for editing, but I have an mg alias in my shell which launches magit for many cases where just git is inconvenient (like, dozens of times per day).
Oh, I’ve recalled one more thing which was hugely important when I was learning magit. It displays the actual git flags which are activated by each shortcut. You can see it on screenshot (shamelessly plugs his own tui rant) here.
(Athor here) Looks definitely interesting, but I think I gotta try it because the documentation looks complicated on first glance. My focus is simplicity and something that does feel like a GUI even though it’s in the terminal.
Definitely give it a shot. Specifically I recommend you try the interactive rebase which you mentioned. It makes it trivial. Everything is one key press away.
I can say it’s probably my favorite piece of software I get to use.
I wouldn’t say SES is difficult. You setup a handful of DNS entries and you’re done. To add more email addresses you just click a link to verify it’s genuine.
As another commenter said, I personally think that email is as important as a mobile phone contact, or ISP. If you ant a quality product, especially for something so important, why not pay for it?
Is Microsoft going to start charging for GitHub Actions at some point or have they come up with some other way to make money out of it? It can’t remain free forever, can it?
Thanks extrawurst! I use gitui for staging and diffs almost every day. It’s ideal to quickly revert some lines. Great time-saver.
For commits I still prefer the cli where you can use a proper editor (vim in my case).
thanks for the feedback! appreciated!
Nice, simple explanation. I hadn’t known about “cargo tree -e features” (I’ve also never needed it).
Thank you! Yeah it’s rare enough that I always have to look up how to do it. Thought it helps others like me too
Reasonably, I believe this to be the best TUI for git I’ve yet to find. The features and straightforward nature of its operation make it a joy to use, and a very useful addition to my toolbox. Could it be slightly more customizable for my workflow? Maybe. But I adore it all the same and find it indispensable. These new additions and enhancements only serve to further distinguish it.
I’m not not running
brew update && brew upgradeon my systems right now like a madman.Hey thanks for the kind words.
What do you use to install it if not brew?
No I do use brew and it showed up immediately! I was just in a hurry to get it, is all.
I’ve also basically switched to it, but one thing does annoy me: it seems to eat control-z so I can’t background it. I presume this was done for a reason (someone had to write the code to do it) and I’m curious what the motivation was.
That is not done explicitly or intended, do you know if that was different in any prior version?
It’s been the case since I started using it about a year ago.
See https://github.com/extrawurst/gitui/issues/1077
Yay! Now if only I could work out why selecting multiple lines doesn’t work in macOS for me. The tool is largely useless without that (so frustrating to stage lines one at a time) but it looks like it doesn’t affect people other than me.
Sorry to hear that this makes it useless for you. Feel free to add more info to reproduce the problem in the GitHub issue. So far it seems you are the only user with that problem
I’m really stuck: I haven’t got any custom settings in my terminal, I don’t think I have anything weird in my environment, I’m using the version from homebrew so not even building my own version with a potentially-broken toolchain. Yet holding shift while pressing arrow keys acts as if shift is not held. If there’s anywhere I can stick debugging logs and build it myself, let me know. I was using gitui a lot on my Windows laptop, but I gave that machine back when I resigned so can’t reproduce the environment where it worked for me anymore.
I am a huge fan of this software. It works great and I prefer it to my other favorite,
tig, which seems a little less friendly thangituidoes.thank you ❤️
Yeah, thank YOU! I guess I need to spend some time learning how to configure things better and such. It’s on me to become a power user, expert operator, competent enthusiast, etc.
Well there are probably a lot like you, so please consider making this a blog post, video or something - we will gladly share this on the project page :)
I’ve been looking for good cross-platform FOSS alternatives to GitHub tools or VS Code for pretty git interfaces, and gitui is the winner for me so far. It’s definitely made it easier for me to manage git repos even with its incomplete feature set, and as this release demonstrates it is quickly gaining functionality, making it even more pleasant to use.
I will mention a specific pain point for me: gitui supports creating tags and pushing tags, but it doesn’t appear to support annotating tags. For git commits it supports opening the commit message in your editor if you want to write more than one line, why not do something similar for annotating tags?
i don’t know if you’ve tried magit but it is hands down the most phenomenal way to use git in my opinion. downside is that you have to use emacs but you could probably tie it to a pared down version of it which i might just try to get going this weekend. despite it being tied to emacs it’s well worth the time to load up and use it. spacemacs has a decently polished layer that includes magit and vim customizations that make it all work well together.
gitui does not force any particular text editor on you 👍
Neither does magit, in fairness, except for the editing of commit messages. And even then, you can use vi keybindings.
I intend no snark by pointing this out; I have colleagues who used other editors and only touched Emacs for magit.
That said, it’s great to see a good GUI for Emacs building momentum. I’ve seen so many new and junior Devs utterly confused by Git. (This is in part to do with how it’s usually taught, but also that the CLI is IMO quite confusing to learn).
How is this a “good GUI”? It looks like an IBM CICS application for a bank backend.
Didn’t you hear? The future of developer UIs is ncurses stomping on a human face, forever.
I’m still holding out for a gesture-based interface to Git.
They’d all be rude gestures, mind you ;)
gitui is not “for” emacs. its a general terminal application
Ah, braino. I meant “for git” :-/
calling emacs a text editor is a bit generous ;)
Hi glad you like it! I never annotated a tag 🙈 but it sounds like a reasonable feature request, please file it over on github👍
Done :)
I’m really rooting for this project. Currently I’m relying on VS Code as a GUI for a lot of my git workflow, which at least isn’t reliant on GitHub and can work with other code forges like SourceHut, but it’s still ultimately a Microsoft product and an Electron app I’d rather not require. I’m hoping gitui can make GUIs unnecessary for me.
I’m also slowly familiarizing myself with other tools like https://github.com/dandavison/delta and trying to get better with git commands on the command line, rather than using GUIs when I don’t have to.
Happy anniversary, extrawurst!
thanks man! ❤️
My open source side project for almost a year now is GitUI: https://github.com/extrawurst/gitui A fast Terminal-UI for git written in Rust.
It got especially rewarding when people started contributing❤️
You could probably achieve similar results using a streaming decoder for JSON, but as with flatbuffer libraries I haven’t seen many around, and I doubt the code would me much more readable than the one using flatbuffers shown in the post.
yeah I wasn’t able to get the streaming decoders for JSON running and the advantage of FB was still that you have random access to at all times into the buffer
oh wow, I didn’t know there was this much language support for flatbuffers. I wonder how well the js implementation works in mobile web.
Yeah its pretty well supported although for us mostly CSharp+Rust mattered
This benchmark is pointless and misguided. You are not likely to draw such a large number of lines in your game on a single canvas item, unless you are willingly abandoning benefits that the engine gives you for nearly no gain. All the real work is done by VisualServer, to which the calls are passed. Basically, all this benchmark measures is how fast can the language process sin/cos calls and call other code.
And the tested options have no real difference in performance when tested for realistic conditions! I’ve decreased the number of lines drawn in each test, until the frame rate hit stable V-Sync(60 fps) on my (quite old and GPU limited) Thinkpad. Both GDScript and Rust options hit 600 lines, and only VisualScript lagged behind with 550 lines. The line count tested in the blog post was 10x bigger! 6000 lines is likely more lines than your screen has vertical ones!
But I can say that tweaking with the numbers was a lot easier in GDScript and VisualScript than Rust. In those two I could just change the variable easily in node properties, while for Rust I had to change the code and wait for 4-5 seconds for it to compile.
Always good to start a supposedly objective comment with such a personal note. Thanks for that :)
My intention was to test performance of sending commands between the programming language and the engine api. this is why the amount of lines matters because increasing the load increases the measurability of the performance differences.
Regarding value tweaking: the variables like the amount of lines is exposed as a variable you can tweak exactly like the ones in gdscript so no recompilation required.
I’d love to see the same comparison with C++ and C#. C# is AoT-compiled with Mono, but is still a safe language and so I’d expect it to be slower than C++ or Rust. I’d expect Rust and C++ to be equivalent performance.
I’ve not ever used Godot but it looks sufficiently interesting that I’m hoping to play with it over Christmas. I’d expect to always use GDScript for rapid prototyping and then move to either C# or C++ for anything that turns out to be a bottleneck after profiling and I’m curious about what the perf delta is between C# and Rust or C++ and whether it’s ever worth going all of the way to an unmanaged language.
Given the rest of the thoughtful reply, I think the first sentence is entirely unintentional in its tone.
**edit, I meant to ask, “Are you looking for feedback?” Because there was no submission comment, it is just a link.
I do think you have an opportunity for a second edit of your benchmarking post. I think outlining just how much the number of draw calls is outside of a normal usage and that the other two solutions are totally workable is a good distinction. Benchmarking is hard and in that direction, we need to constantly apply hygienic practices.
I also think it is important to go into the why and how one would measure it. Is it interpreter overhead? Memory allocation? Type checking? Or maybe the Rust code gets inlined, who knows?
One thing I would have like to see is
For bonus points, drawing a flame graph of each run would be amazing.
Two folks I really look up for benchmarking and technical analysis are
I don’t understand what you mean. I said that this benchmark is pointless and misguided. It is pointless because it is measuring performance of code that is not likely to appear in real game code, therefore failing to provide any meaningful insights. It is misguided because what it is trying to measure is not indicative of real performance you are likely to see if such workload was actually used, as it does not measure the time it takes VisualServer to actually render the lines as the draw commands are queued until it’s time to draw.
For that to avoid confusing people you should have chosen an example which is obviously doing just that, e.g. using engine’s print function. Currently, if remove the draw_line call, the performance ratios do not change between the languages, which suggests that what this benchmark is actually measuring is how fast can languages calculate sin/cos.
Oh, actually didn’t notice this because Rust has no default struct values, which I was looking for when trying to change the iteration count. Slightly annoying, but it is possible, so I do retract that statement.
I hadn’t heard of lazygit before, a TUI you list as an inspiration. gitui doesn’t have the features I need yet, but it looks like lazygit, which is more mature, does. For example, lazygit handles a lot of interactive rebase cases more smoothly than either my main Git GUI Tower or
git rebase. So thanks for the pointer.Can you go into more detail about what problems lazygit has in the “too complicated to use and navigate” category? Have you planned how you will avoid those interface problems in gitui yet?
Cool that lazygit works good for you.
My vision for gitui is to make it a terminal tool, that is still as easy to learn as a regular GUI. Where I find most alternatives are embracing the ‘I am a terminal tool, expect to be confused by tons of shortcuts and a man page to learn them’-style. I want to have a clean UI that only offers the kind of shortcuts that are applicable in the current situation so that they always fit into a quick-bar on the bottom. simplicity and speed are my motivations. hope that makes any sense :)
For me it was too much of a memory/cpu hog and too slow on big repos. As I am mostly on battery I cannot afford that. Opening lazygit in the linux repo, keeps 1 core busy permanently, fills up to 3 Gig of Ram when scrolling through the commits and grinds to a halt once it parsed all 900k commits.
Love it. You should definitely checkout magit for some UI ideas. It’s superior to everything I’ve used in that sense, and I think anyone that has used it feel the same.
Link for convenience: Magit, a Git porcelain inside Emacs
Yup, I don’t really use Emacs these days for editing, but I have an
mgalias in my shell which launches magit for many cases where justgitis inconvenient (like, dozens of times per day).What use cases are that so that I can see what to implement next in gitui?
Thanks!
Oh, I’ve recalled one more thing which was hugely important when I was learning magit. It displays the actual git flags which are activated by each shortcut. You can see it on screenshot (shamelessly plugs his own tui rant) here.
Really interesting but gitui is not using the git shell under the hood so I think that is not really a matching purpose I am afraid
(Athor here) Looks definitely interesting, but I think I gotta try it because the documentation looks complicated on first glance. My focus is simplicity and something that does feel like a GUI even though it’s in the terminal.
Definitely give it a shot. Specifically I recommend you try the interactive rebase which you mentioned. It makes it trivial. Everything is one key press away.
I can say it’s probably my favorite piece of software I get to use.
Either way nice work!
I wouldn’t say SES is difficult. You setup a handful of DNS entries and you’re done. To add more email addresses you just click a link to verify it’s genuine.
As another commenter said, I personally think that email is as important as a mobile phone contact, or ISP. If you ant a quality product, especially for something so important, why not pay for it?
For a dev it might be. I tried to find a solution that is simpler to setup and optionally useful for friends of mine
Is Microsoft going to start charging for GitHub Actions at some point or have they come up with some other way to make money out of it? It can’t remain free forever, can it?
https://github.community/t5/GitHub-Actions/GitHub-Actions-Pricing/td-p/40975