The Lazy Git UI You Didn't Know You Need
Key topics
The article introduces lazygit, a terminal UI for git that simplifies complex git operations, and the discussion highlights various git tools and workflows, with many users sharing their positive experiences with lazygit and other git interfaces.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
51
3-6h
Avg / period
10
Based on 160 loaded comments
Key moments
- 01Story posted
Nov 10, 2025 at 12:50 PM EST
2 months ago
Step 01 - 02First comment
Nov 10, 2025 at 2:38 PM EST
2h after posting
Step 02 - 03Peak activity
51 comments in 3-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 12, 2025 at 1:18 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Now I no longer directly use git, but instead use jujutsu (jj).
Once I became very proficient in the jj cli, I picked up jjui: https://github.com/idursun/jjui
Also, as splitting commits is an extremely frequent operation, this neovim plugin is really nice: https://github.com/julienvincent/hunk.nvim
Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts
Now with jj instead of git I edit the commit graph as effortlessly as if I am moving lines of code around a file in my editor.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
Thanks again!
A tool like https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
https://git-scm.com/book/en/v2/Git-Tools-Rerere
In my experience with jj when resolving a conflict, as long as I do it in the earliest change, I will only have to do it once.
Git has the rerere setting [0] which reduces the need to resolve the same conflict over and over
0: https://git-scm.com/book/en/v2/Git-Tools-Rerere
So you can use any diff tool you like with git, and I presume also with JJ. Look for the setting.
Edit: in git it's the diff.external setting
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
I’m sure I’m not the first one to have that thought. So I’m curious what other tools and systems people have built in top of git.
There are really only two things I care about: the state of the files on disk and the state of the index. And I really only care about where I am and where I want to go, everything else in the middle is noise.
To me, the staging area isn't "real", it's just a tool for working with the other two. Git doesn't need to pitch a hissy fit about editing history. Allowing easy edits of history would obviate the need for the staging area. But because they called it "history", now we have emotional responses to the concept of editing it, like we're somehow committing political revisionism.
But the existence of the staging area and the attempt at making the DAG look linear makes reseting ridiculous. Every time I need to do some kind of reset that isn't --hard, I have to read my Git GUI's descriptions of what each type does, and yet somehow it still doesn't have the combination I actually want half the time. All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index. Sometimes I end up having to do a two step reset of a combination of hard forward then soft backwards to get what I want.
Similarly, all the different merge strategies are dumb. None of them ever do the right thing. I'm always getting stupid shit like new blocks that insert a new ending curly brace after the previous block, followed by the new block body, then the original ending curly brace from the old previous block. Half the time I just use the reset hard/soft to then manually review changes to enact a manual merge rather than trust merge to do anything reasonable.
Sacred history makes it way too hard to organize commits in any logical way. I want my VCS to be a super-powered UNDO. I don't need it to be an audit log of who did what and when (auditability only matters for releases so why do I have to be saddled with it minute by minute?). I basically want to be able to edit two or more commits in a sequence as easily as I currently can edit the staging area, so I can easily guarantee ordering of changes to partially related modules that I'm working on together. C depends on B depends on A. I want to be able to work on all three at the same time, but make sure all changes to A come first, then B, then C, and I want to be able to do this incrementally over the course of the day, rather than all at once when everything is perfect.
But this fetish of not changing history even though we can totally change history biases all other Git tooling to attempt to appear like it operates in linear history. Like how there's the HEAD pointer that can be offset; uuuh, what happens if that offset reaches a fork (I've never tried, the poor DAG experience of the CLI has kept me in GUIs which makes the HEAD pointer completely unnecessary). Or how log is basically unreadable.
Don't even get me started on submodules vs subtrees. I have to get to work.
It sounds to me like you want `git restore -W` and `git restore -S`.
I'm having a hard time understanding the issues you're having with reset and the workflow. It sounds to me like you just need to do something like "commit 'WIP A'/'WIP B'/'WIP C'" and fixup them as desired. Things like https://github.com/sjurba/rebase-editor make it a lot faster to do this. It wouldn't be too hard to make a small script/alias to do something like "modify commit A with <staged>, stashing the rest, rebase B->C on top of A, unstash", and assuming they aren't touching the same lines significantly, it wouldn't conflict much. But this could be way oversimplifying what you want.
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
Which is why jj is interesting, it managed to find a way to coexist within the Git monoculture rather than swim against the tide like Mercurial, Darcs, Pijul, Fossil
And if something becomes really hard to do with git, I found that often the problem are on the project itself.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
https://www.visualjj.com - I'm building it and would appreciate any feedback!
How about tig?
The please is because I am tired of fixing issues created by people being confused by git. Just use anything else than the git cli, it's probably better.
ctrl+f "tool"
I'm trying jj. I've seen enough mentions now. I've never read anything about it.
I hope it's compatible with git.
Or if you don't care to set a commit message just yet: jj split -i
Or if you want to defer making sure each commit has the right content until later, just use jj new, and then later use jj squash and jj split to make the commits have sensible changes, and jj desc to set the descriptions.
If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried.
Its file status and history view is unmatched IMO. I can easily stage/unstage hunks and even lines. The whole UI is generally quite polished and pleasant to use.
It's a real shame there is not a version for linux. I've tried every other git interface under the sun and keep coming back to it. In the meantime, I tried lazygit the past weekend and I think it is one of the better TUI git tools out there, definitely better than GitUI.
[0] Well, plus git-mediate for solving conflicts
[1] https://github.com/bolivier/jj-mode.el
We'll see once better non-cli UX appears. I'm low-key excited for what could be possible in this space.
FWIW, jujutsu was an improvement over git for me in about 5 minutes of using it.
[0] https://github.com/altsem/gitu
Despite having some annoying aspects, it is (as if you even needed to ask) still better than using the command line, and, importantly, has yet to annoy me enough to actually switch to something else. Though as an Emacs fan I do have Magit on my list.
I probably will switch back to ST even at work because I dislike:
- I want the split view of ST where I can simply see the changes and not lose the commit log.
- “see only current branch” is super useful in ST to see only the current branch’s commit log.
(Partially writing this in hopes of someone pointing out ways to do this in Fork)
Also if you, like me, wanted to blame or view history for specific files there does not seem to be a way by clicking in the GUI to achieve it. But by using Ctrl+P you get the command search and can search for "Blame" or "File history".
No, please throw SourceTree into the garbage can.
These days I use VSCode and the Git Graph extension.
It's a bit of an odd one, and it has a bit of a learning curve, but it's free (as in beer), relatively easy to install, and seems to work well for me. I haven't found a FOSS tool that I like as much yet.
Now that they updated the interface I've had problems. Ch l crashes and difficulty to install as non admin.
People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.
A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.
I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.
Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.
One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.
I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
One of the main things I like about it is that it does _not_ auto refresh. A long time ago with SourceTree I'd have issues mixing git CLI and SoureTree because two processes would be doing things at the same time (I assume SourceTree was doing things like `git status` while I was trying to `git fetch` or something).
https://git-extensions-documentation.readthedocs.io/en/main/...
I found lazygit specifically so bad to the point that I was better off typing in git commands into the terminal manually like some sort of caveman. Somehow, lazygit has found a way to make git even more confusing and user hostile than it already is, which is a significant achievement.
Using it was a harsh reminder of what people running emacs or vim for the first time have to go through.
This idiotic ui paradigm where you have to actively learn to use what should be simple software by memorizing commands and shortcuts needs to die off. It's mind bogglingly inefficient and disrespectful of user's time.
Just think about it - I've literally never had to open Fork's manual (I am not even sure it has one) whereas in lazygit it is utterly impossible to do the most basic things without referring to the manual. Why do we collectively keep tolerating these shitty tools?
"Using it was a harsh reminder of what people running emacs or vim for the first time have to go through."
The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
Mouse-driven tools like VS Code don't demand that the user learns them. Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to. This adds on seconds per interaction, adding up quickly over time.
+And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet. For Vim this can be a huge lifesaver; I made one for magit as well, back before I switched full-time to JJ.
I have never been rate-limited by my keyboard input speed. I have lost many minutes of time daily looking up cheatsheets for terminal tools that I use occasionally.
Ironically, when I see what impact AI has had on my programming, the biggest has been in saving me time crafting command line invocations instead of browsing <tool> --help and man <tool>.
This is simply not true and I say this as a life long vim user. The only reason I have vim mode enabled in all the editors that support it, is the fact that it's immensely difficult to retrain muscle memory accumulated from a decade+ time sunk in that editor. Nothing about vim or any of these other tools being keyboard driven, make me more productive in a way that matters.
> Mouse-driven tools like VS Code don't demand that the user learns them.
Good. That's how all software should be. It's a means to an end, not the center of the universe. The whole reason for bringing a UI layer into all of this in the first place is freeing up my brain from having to deal with git's bullshit.
> Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to.
The shortcuts are still there if you care to learn them - it should absolutely not be a prerequisite.
> +And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet.
Or, I could use some actually well designed software and save myself some printer ink :-)
Or, you could use some well-designed and self-documenting software. Too bad there's not much of that besides Emacs - on the other hand, Emacs and occasionally a browser cover most of my computering needs...
Honestly, I found the barrier to entry way lower with lazygit than with vscode.
I realise I'm not adding anything useful to this discussion. I tried to start VSCode so that I could evaluate it and, maybe, add some info. as to why I find it more difficult to get into, but it just crashes now :shrug:
I managed to get on fine with lazygit during a quick trial this morning. It actually doesn't have a manual (`man lazygit`: `No manual entry for lazygit`) but I found the contextual help (e.g. press ?) useful.
It is not, but git absorb only produces fixup commits, you can still change what they change in the autosquash step.
So I agree but unfortunately it's the norm and policy for some clients.
Git-absord by default doesn't squash the fixups though, it creates new ones with special tags for easy rebasing later.
Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
1. Fork: https://git-fork.com
2. Kaleidoscope: https://kaleidoscope.app
3. GitUp: https://gitup.co
4. Tower: https://www.git-tower.com/mac
But the main use I get from it is for incremental index adding, so maybe not as much as OP.
[1] https://jonas.github.io/tig/
1. Choosing what to commit and committing it, fixups, autosquash
2. Conflict resolution and history investigation
It's very rare I've wanted a separate tool for the first, and the second calls for a GUI tool.
And when you do, git log has "--graph --oneline" to do just that.
I have an extended version in a bash function because I do do it often and it's much easier/faster than opening a separate tool.
I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be inside neovim or "switch" to the LazyGit UI. It just overlays it on top of whatever I'm doing at the moment in the terminal.
Makes for the most fluid, streamlined git experience ever if you primarily live in the terminal.
Oh yes, I use lazygit as a separate binary (brew installed) from separate terminal shell all the time. No need for nvim!
Great to hear you can neatly configure similar UX (popup) with tmux!
For instance, you can visually select a range of lines in a file, and stage those lines.
This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot.
I have found it useful to fire up "git gui" during rebase workflows with conflicts. It helps with the "git add" commands you would have to do to add conflict-resolved files into the patch and whatnot.
Isn't this the standard for every Git GUI? Are there people who use a GUI that can't do that?
It would be pretty pointless to go out of the way to use something that doesn't come from the git project, yet is less capable (unless it had some overriding killer feature for the sole sake of which it was invoked).
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache.
But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does fine) still takes the cake for that, as the clarity and lack of keyboard bindings, is essential; to make good, conscious decisions.
[1] https://git-fork.com
This seems a very solid rule.
Given that Fork is a two-person family company that’s somehow managed to make the best Git client in the world for a single reasonable price with free updates and no subscription, I’d suggest that it’s worth paying for to keep their business sustainable.
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
[1]: https://github.com/mroth/scmpuff
[2]: https://github.com/dandavison/delta
Really happy to see it featured here, I became a convert couple of years ago after switching to Astronvim (lazyvim is bundled with it).
git gui → Amend Last Commit → (select lines from a file in the Staged Changes area) → Unstage Lines From Commit → Commit
I still think it's the perfect does-just-enough GUI when the main thing you want is to visually craft commits.
Lazy git checks off a lot of boxes. Easy tool to adopt to speed up and simplify your git workflow
https://github.com/jesseduffield/lazygit?tab=readme-ov-file#...
So with a newer non-LTS ubuntu you can just apt install lazygit, with 24.04 it's
``` LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/..." | \grep -Po '"tag_name": "v\K[^"]') curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/download/v..." tar xf lazygit.tar.gz lazygit sudo install lazygit -D -t /usr/local/bin/ ```
62 more comments available on Hacker News