GitUI: Terminal UI for Git(github.com)
github.com
GitUI: Terminal UI for Git
https://github.com/extrawurst/gitui
93 comments
Any tig users here ? I’m happy with it since then, looks like the feature set is pretty similar
tig rules.
gitui does not support vim keybinding for me, or I did not find out how.
rust's size always surprise me:
tig -- 600KB, gitui: 11MB
similar size pattern for other utilties, in general, rust executable is about 200x larger than its c/c++ peers, and, they all linked to similar c/c++ libraries, looks like rust stdlib is pretty big in size to me.
gitui does not support vim keybinding for me, or I did not find out how.
rust's size always surprise me:
tig -- 600KB, gitui: 11MB
similar size pattern for other utilties, in general, rust executable is about 200x larger than its c/c++ peers, and, they all linked to similar c/c++ libraries, looks like rust stdlib is pretty big in size to me.
looks like there's a key binding file to enable vim bindings.
Having said that, I'm also a tig user and at least at first glance, I prefer its simplicity. Gitui presents a huge amount of info on the default screen and spends quite a lot of real estate drawing borders around everything. Tig just takes me straight to the commit history, full screen and then I have single key actions to get to other views.
The only thing I don't like with Tig is how little it binds to keys with the expectation that you set up your own mappings to git commands. I would prefer it baked more of them in so they would be standard and documented ... but that is a minor complaint.
Having said that, I'm also a tig user and at least at first glance, I prefer its simplicity. Gitui presents a huge amount of info on the default screen and spends quite a lot of real estate drawing borders around everything. Tig just takes me straight to the commit history, full screen and then I have single key actions to get to other views.
The only thing I don't like with Tig is how little it binds to keys with the expectation that you set up your own mappings to git commands. I would prefer it baked more of them in so they would be standard and documented ... but that is a minor complaint.
+1 for opinionated-tig.
IIRC rust statically links crates used by the application, so it might not just be the stdlib that is causing this.
rust binaries are statically linked, that's the big difference. If you included all the libc code statically in most c programs they'd probably also be pretty big
Go programs are also statically linked and Go based CLI tools generally only come in at 3-4 MB IIRC. I've used static linking in binaries in Nim and C programs too with similar (or smaller) sizes.
Rust binaries are just impressively large. I'd guess part of it must be how Rust monomorphizes generics: https://rustc-dev-guide.rust-lang.org/backend/monomorph.html
Rust binaries are just impressively large. I'd guess part of it must be how Rust monomorphizes generics: https://rustc-dev-guide.rust-lang.org/backend/monomorph.html
if you strip them you tend to lose a lot of the fat.
Nice, any tips on how to do that? Is there a Cargo thing or just run regular ole strip?
strip will help to some extent, like 20% downsize, just not enough
when i have an embedded board with say 64mb storage,a few rust executable will fill them up fast. problem is that rust does not give me option to do dynamic link to its stdlib.
Not that this is based on some Googleing and experimentation; I could not find official docs.
It actually is possible to dynamically link to the standard library. Add this to your project's .cargo/config.toml file:
https://github.com/WilliamVenner/prefer-dynamic
After you do `cargo build --release`, you will notice you hello world EXE is much smaller than a typical rust binary. Like 10~20KB small. On Windows it runs just fine. On Linux, I has to change the exe's RPATH to look for the standard library in the current directory:
It actually is possible to dynamically link to the standard library. Add this to your project's .cargo/config.toml file:
[build]
rustflags = ["-C", "prefer-dynamic"]
https://github.com/WilliamVenner/prefer-dynamic
After you do `cargo build --release`, you will notice you hello world EXE is much smaller than a typical rust binary. Like 10~20KB small. On Windows it runs just fine. On Linux, I has to change the exe's RPATH to look for the standard library in the current directory:
patchelf --set-rpath '$ORIGIN' ./exe_name
as far as i know,this is not officially supported.rust links to its stdlib statically by design. when you have to share this stdlib with a few dynamically linked rust crates it's hard to do in practice.
tried all size reduction tricks,still the size is much large,like 15x large than c,c++. even the stdlib is a 3x larger than to libstdc++
tried all size reduction tricks,still the size is much large,like 15x large than c,c++. even the stdlib is a 3x larger than to libstdc++
by default rust doesn't statically link to libc.
gitui has much bigger feature set than tig. Rust binaries might be larger because Rust makes creating complex software possible.
"With friends like these who needs enemies?" All these glowing recommendations and no one shares the URL?
https://jonas.github.io/tig/
https://jonas.github.io/tig/
Tig combined with this vim plugin is big part of my workflow: https://github.com/iberianpig/tig-explorer.vim
Tig is just awesome. So well thought out, with sensible shortcuts for every relevant action in each context. Must have gone a lot of thought into it.
I use tig daily. I've never used anything I like as much for quickly browsing through commits in a repository or staging individual hunks.
how does tig compare to something like magit?
It only does a fraction of what magit does. I just use it for scrolling though the commit history, occasionally searching messages, and it's my tool of choice for staging/unstaging hunks.
It's the only tool I use to compliment the git cli.
It's the only tool I use to compliment the git cli.
I see. have you tried magit as a comparison? while magit can do everything it's got a very easy interface for most tasks. I don't use emacs for anything but magit to the point where i have a magit command on the command line to open up emacs in the current directory and then a spc-g-g opens up magit. it's that good.
So I use neovim as my editor, I'm familiar with fugitive but only use it for blaming.
I just prefer switching to my git tab in tmux and using the cli or tig deepening on what I'm doing.
I just prefer switching to my git tab in tmux and using the cli or tig deepening on what I'm doing.
Happy tig user. Viewing git history without it is painful.
I used tig way back in the day, but I have found `magit` to be superior and one of the most useful emacs packages that I use daily.
Yep tig is my world.
Nothing wrong with tig. It just works.
tig is perfection
tig is better
Lazygit is an alternative which worked great so far for me
https://github.com/jesseduffield/lazygit
https://github.com/jesseduffield/lazygit
Just tried Lazygit and one thing that stands out is it is the first of these tools that offers some kind of support for submodules (like, I can select a submodule and then navigate into that context and back out again).
It's great that all these options are becoming available and bringing ideas into the mix.
It's great that all these options are becoming available and bringing ideas into the mix.
Gitui's README mentions that Lazygit freezes and sometimes crashes parsing large repos, taking the example of the linux repo, and reports that Gitui is more than twice as fast: https://github.com/extrawurst/gitui#3--benchmarks-top-
At least for the stability issues, does this match your experience?
I see others have mentioned tig here as well, I'd be curious to hear if they also find it somewhat slow and unstable. Gitui's linux benchmark lists it as being almost 11 times faster than tig.
At least for the stability issues, does this match your experience?
I see others have mentioned tig here as well, I'd be curious to hear if they also find it somewhat slow and unstable. Gitui's linux benchmark lists it as being almost 11 times faster than tig.
I use tig intensively and it does sometimes have little freezes etc but only on giant repos AND where the file system is slow / busy. Its a 2nd or 3rd order type problem to me. If you work all the time on that type of repo it might be more important.
I use tig and with 200k commits, walking the log goes a bit wild so the trick is too just default to loading a maximum number of commits etc.
There's a sample config in the repo on how to manage large repos
There's a sample config in the repo on how to manage large repos
I've used this non stop for months now, it's so good! You can get it from neovim as well as your git plugin and merge resolver if you don't want to use fugitive or something else. https://github.com/kdheepak/lazygit.nvim
I'm a long time user and big fan of lazygit. It substantially increases my productivity for the most common tasks. I am a sole developer working on multiple web site projects.
The design works very very well for me.
The design works very very well for me.
Shoutout to lazydocker by the same author. One of my used apps
Same, never had a problem with lazygit.
At some point I often wonder why people are so damn intent on living in their terminals. This is an ASCII GUI with the exact same feature set that `git cola` offers which is extremely lightweight and keyboard friendly. The only difference is you can't click on something if you forget the keyboard shortcut.
I really enjoy having multiple apps and editors running in tmux splits. I’m very fast in it and it helps keep me focused.
Magit is an excellent and widely used Git TUI.
Have relied on magit for so long now I am not even sure if I "know git" anymore. Definitely can't imagine doing a complicated rebase without it, or (ab)using stashes so much.
But only available in Emacs
Emacs is basically a textual application library (a curses alternative). It's often perceived as a text editor, but not using Magit because it's implemented on Emacs is like not using X because it's implemented on curses
AFAIK a magit stand alone client exists
Anyway, I'm a happy user of this for VS Code
https://marketplace.visualstudio.com/items?itemName=kahole.m...
Anyway, I'm a happy user of this for VS Code
https://marketplace.visualstudio.com/items?itemName=kahole.m...
What's the learning curve if you're not an Emacs user?
I suspect it’s possible to only learn a few things, e.g. C-g to get unstuck, C-x C-c to quit, some config to have a key to open magit status or a clever bash alias, and then the keys in magit for which there is documentation (regular Emacs is also documented) and semi-documented in that when you e.g. press c to start a commit, a pop up appears with eg flags you can set or commit-like actions like reword/amend.
[deleted]
It's quite linear if you're using the manual / C-h prefix. More like a spiral if you're like me and keep reaching for external packages to solve problems you're not sure you have. Either way it's really worth it.
Emacs with spacemacs or doom-emacs’s spacemacs layer (both lf which use vim bindings aka “evil mode”) is quite similar to vim as far as text editing goes. For me this made the initial learning curve pretty approachable.
And neovim (via neogit)
Do you happen to know if neovim has a helm-ag analog? For the most part that and magit are the only two things I use in emacs anymore and would love to try something lighter weight.
Neogit is a magit clone rather than secretly actually using magit code, right?
At least until they add an elisp interpreter to vim.
Magit also functions as a proper git GUI with the Emacs GTK interface.
Just wanted to mention this in case anyone was under the impression that Magit was TUI only!
Just wanted to mention this in case anyone was under the impression that Magit was TUI only!
I’ve heard great things, but the Emacs dependency is a huge turn off.
I'm by no means an expert, but is it really that hard to remember clone, pull, commit -a, push and maybe something else you'd need. That you need a GUI? And even then you can either use the help or man or just Google it and you'll remember the right command sooner than later.
Or am I missing some quite important? I've been using this for most of the stuff that I do in github and it seemed to be enough.
I use these on my Chromebook, but on my stationary computer I just use the integration in VS Code.
Or am I missing some quite important? I've been using this for most of the stuff that I do in github and it seemed to be enough.
I use these on my Chromebook, but on my stationary computer I just use the integration in VS Code.
> Or am I missing some quite important?
I feel like you are. The operations you mentioned - clone, pull, “commit -a”, and push - are trivial. Nobody needs a nice UI for those.
But in real day-to-day use, I’m branching, merging, creating and applying stashes, cherry picking, rebasing, browsing the repo history, browsing specific file histories, diffing across branches, selectively committing specific changes in a file, etc. and it’s convenient to have a nice UI for the more advanced use cases.
I feel like you are. The operations you mentioned - clone, pull, “commit -a”, and push - are trivial. Nobody needs a nice UI for those.
But in real day-to-day use, I’m branching, merging, creating and applying stashes, cherry picking, rebasing, browsing the repo history, browsing specific file histories, diffing across branches, selectively committing specific changes in a file, etc. and it’s convenient to have a nice UI for the more advanced use cases.
People who use commit -a terrify me. The value of a tool like this is it makes it trivial to review changes, stashes, etc. in a convenient way without needing to look up commands. This tool in particular is built to handle huge repos which most other front ends straight up can't. And it does it with a 1mb binary and almost no ram.
Definitely agreed. My workflow for a commit is always:
git status
git diff HEAD
git add (usually -u)
git commit
git add -p is my default. Usually what I have been up to belongs in 2-3 separate commits, each with a good commit message. For example a bug found and fixed while developing a feature always goes in its own commit.
> Or am I missing some quite important?
Speaking as to "why would you not just use command line git, or VSCode integration".
Two aspects: Speed, and discoverability.
These are two things that magit massively improves upon the command line.
e.g. to make the commit, in magit, it's the key sequence "<Spc> g g" (to open magit) then "c c" to commit. (Being able to quickly do this from the same place you edit code is very convenient).
In terms of discoverability, magit shows me the common options for commands (e.g. it shows `-a autostash` for git pull), or other commands which might be useful that I've not used (like git worktree).
Speaking as to "why would you not just use command line git, or VSCode integration".
Two aspects: Speed, and discoverability.
These are two things that magit massively improves upon the command line.
e.g. to make the commit, in magit, it's the key sequence "<Spc> g g" (to open magit) then "c c" to commit. (Being able to quickly do this from the same place you edit code is very convenient).
In terms of discoverability, magit shows me the common options for commands (e.g. it shows `-a autostash` for git pull), or other commands which might be useful that I've not used (like git worktree).
I use a git GUI (Sourcetree) as a time saving tool to visualize the git repo, browse through commits to view changes, diff non adjacent commits or branches, etc. I have never used it to actually alter the state of my repo, all that is much easier on the command line for me. But TUI is woefully inadequate for getting the hang of even a moderately complex repo that I'm trying to understand.
I use an alias like this:
> gac Update controller
which means “git add all and commit with this message” very rarely do I make a mistake with this. Maybe once every 3 weeks, in which case I just restore the file I accidentally added.
> gac Update controller
which means “git add all and commit with this message” very rarely do I make a mistake with this. Maybe once every 3 weeks, in which case I just restore the file I accidentally added.
no but it (at least tig) facilitates navigating the graph, partially staging etc.
I use fugitive, a Git interface that operates from within [n]vim. There are many advantages to using Git from within an editor, especially as so many Git operations land you in an editor in any case; this way, you stay in your editor context, so, for example, you get completions from your other windows when composing your commit messages.
I have used vim-fugitive for years to read large and small codebases. Its blame and re-blame interface is the best I've found.
Have you used magit?
If there's a better one out there than magit's, I want to know.
If there's a better one out there than magit's, I want to know.
I haven't, but I don't use emacs. Crash course:
`mkdir -p ~/.vim/pack/git/start`
`git clone https://github.com/tpope/vim-fugitive ~/.vim/pack/git/start/vim-fugitive`
Open a file under version control and `:Git blame`
The commit shas, author, and date appear in a window to the left. `Ctrl+w Ctrl+w` to switch windows. Both windows scroll up and down together.
Pressing `o` on a commit sha opens the full commit log and patch in a window below. Close this with `:q`
Pressing `~` on a commit sha re-blames on parent (git's ~)
Pressing `P` on a commit sha re-blames on parent (git's ^)
There's also a set of (old and a bit outdated) Vimcasts on fugitive, episodes 31-35 http://vimcasts.org/episodes/archive/
`mkdir -p ~/.vim/pack/git/start`
`git clone https://github.com/tpope/vim-fugitive ~/.vim/pack/git/start/vim-fugitive`
Open a file under version control and `:Git blame`
The commit shas, author, and date appear in a window to the left. `Ctrl+w Ctrl+w` to switch windows. Both windows scroll up and down together.
Pressing `o` on a commit sha opens the full commit log and patch in a window below. Close this with `:q`
Pressing `~` on a commit sha re-blames on parent (git's ~)
Pressing `P` on a commit sha re-blames on parent (git's ^)
There's also a set of (old and a bit outdated) Vimcasts on fugitive, episodes 31-35 http://vimcasts.org/episodes/archive/
okay, thanks very much for the overview!
Any lazygit users that switched over to gitui? If so, what made you switch?
Started with lazygit, but read about gitui at essentially the same time. Got used to gitui and it's speed so I stayed. Lazygit is pretty great too.
I mostly use gitui for staging things, it supports file, hunk and line staging, it's meant to compliment git cli, not replace it.
I also use it to manage tags.
I mostly use gitui for staging things, it supports file, hunk and line staging, it's meant to compliment git cli, not replace it.
I also use it to manage tags.
Funny. I thought 'git' was a terminal UI for git.
No, it’s a command-line interface. For a decent illustration of the difference, see https://en.wikipedia.org/wiki/Text-based_user_interface and https://en.wikipedia.org/wiki/Command-line_interface.
[deleted]
Is there a Web UI equivalent for tools like this, where one can spin up a web server pointing to a git repo on the server and do commit, diff, merging, graph visualisation etc. through a web interface?
Not exactly what you are looking for, but github.dev provides much of this for repos hosted at github. Press . while accessing the repository at github.com to jump right into github.dev (this appears to require me being logged in so it's possible I configured this somehow).
I just started working on a project with this use case in mind.
So far just a "browse" experience somewhat like GitHub, but uglier.
Soon want to add ability to commit, similar to GitHub desktop, but without electron.
Very WIP atm but hoping to work on it some this week.
https://github.com/stereosteve/git-goggles
So far just a "browse" experience somewhat like GitHub, but uglier.
Soon want to add ability to commit, similar to GitHub desktop, but without electron.
Very WIP atm but hoping to work on it some this week.
https://github.com/stereosteve/git-goggles
It doesn't do half of those things but somewhat amazingly there is one built into Git itself:
https://git-scm.com/docs/gitweb
https://git-scm.com/docs/gitweb
Sounds like you want "ungit":
https://github.com/FredrikNoren/ungit
Shameless plug, but i built something similar a few years ago: https://github.com/GitGud-org/Gitgud
Looks great and fast! Nice work! I'm wondering if the missing features for 1.0 will keep it fast. (The first thing I wanted to do is search the log and see the graph :-). Does not look like it.
I use tig (git backwards)
https://jonas.github.io/tig/INSTALL.html
https://jonas.github.io/tig/INSTALL.html
So, the main motivation/benefit over alternatives like tig and lazygit is better responsiveness and fewer crashes? Or are there other considerations?