[HN Gopher] The lazy Git UI you didn't know you need
___________________________________________________________________
The lazy Git UI you didn't know you need
Author : linhns
Score : 165 points
Date : 2025-11-10 17:50 UTC (5 hours ago)
(HTM) web link (www.bwplotka.dev)
(TXT) w3m dump (www.bwplotka.dev)
| varunramesh wrote:
| I use lazygit when I want to stage specific lines rather than an
| entire file.
| magdyks wrote:
| lazygit rules!
| aeve890 wrote:
| I'd recommend lazydocker, from the same author IIRC. Awesome TUI.
| tcoff91 wrote:
| I was a big fan of a good keyboard-driven git TUI like magit,
| neogit, lazygit, etc... (as long as you learn the CLI first and
| understand it).
|
| 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.
| dizzant wrote:
| Thank you for the many tool links! You seems to know this space
| well. I have come to pick your brain for more.
|
| 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!
| stavros wrote:
| Not the GP, but I might recommend Jujutsu for that, try it
| and see. It does the right thing when you resolve commits,
| and it propagates them to git. However, I'm not sure if it'll
| work, try it and see.
| stavros wrote:
| Jujutsu is much better than git, and I've switched to it
| completely, but I do still use lazygit for one thing: It has
| better diff viewing, it separates the diffs by file and they
| look nicer. It's the only thing keeping me on lazygit, as jjui
| is much better otherwise.
| onraglanroad wrote:
| Git doesn't fundamentally work with diffs (patches). It
| stores the complete file and generates a diff.
|
| 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
| stavros wrote:
| I know I can. I want to use jjui, but its UI isn't as good,
| so I use lazygit.
| SAI_Peregrinus wrote:
| There's also lazyjj. I haven't really bothered with a TUI
| yet so can't say which has nicer diffs, but you might try
| it.
| stavros wrote:
| I've tried lazyjj, but jjui was better (at least, back
| when I tried it).
| Zambyte wrote:
| The less I use git directly, the more convinced I am that git is
| an absolutely awful interface to git repositories. I have been
| using jj for about two years now, and I literally cannot imagine
| going back to using the git cli. I have not used lazygit, but if
| you find it interesting, I say please go for it.
|
| 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.
| danielhep wrote:
| I have tried jj several times but I feel like it slows me down
| significantly because I can't grok the workflow. I like to do a
| bunch of changes then quickly select them in my editor and
| commit them, breaking them up into different commits to keep
| them organized. With jj's lack of editor integration, I don't
| know how to do this with the cli alone so I end up with bigger
| messier commits.
| WolfeReader wrote:
| You want "jj commit -i". You'll get an interface that lets
| you choose files, chunks, or lines to commit.
| prmph wrote:
| You might laugh, but in years of serious development, I have not
| come across a better git UI tool than SourceTree.
|
| 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.
| skydhash wrote:
| Did you try magit? There's a bit of learning curve as it's
| built on top of Emacs, but it's entirely keyboard driven. I
| still have to find a workflow that it does not support.
| hahn-kev wrote:
| Do you use the Mac or Windows version?
| prmph wrote:
| The Mac version
| tom_ wrote:
| The Windows version is decent too. They seem to be at least
| partly different code bases, which is nice in some
| respects, but does mean they're not quite the same. The Mac
| version is less good about doing git submodule update when
| required, and sometimes the side panel state can be wrong;
| the Windows version seems to occasionally forget the state
| of the delete after applying option when doing git stash
| pop.
|
| 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.
| 9dev wrote:
| Have you tried the Jetbrains IDE git client yet? It hits the
| perfect spot for me.
| CamJN wrote:
| I find both Fork and Tower to be much better than SourceTree,
| have you only tried free tools?
| prmph wrote:
| I have dabbled in those tools. Still did not change my
| opinion.
| Sammi wrote:
| I can't live without Fork. It's the one thing I miss on
| Linux. I have it in Wine, but it's running terribly there
| unfortunately.
| wingerlang wrote:
| I've used SourceTree for a decade, Fork is the only one
| I've switched to partially (at work).
|
| 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)
| rc_kas wrote:
| There are few UI's that I hate more in the world than
| SourceTree. That pile of junk has cost me so many hours of life
| trying to support the developers in fixing a thousand weird
| issues.
|
| No, please throw SourceTree into the garbage can.
| prmph wrote:
| What exactly were the problems? I have been using it since
| like forever and have not run into any issues at all.
| Granted, like I said, I don't use it for any hard-core stuff.
| ericfr11 wrote:
| I've used SourceTree for years, and for advanced flows, with
| an external tool for diff. Never failed me from the base,
| squash, orphans, forks,...
| darknavi wrote:
| For staging/committing I haven't found anything that I've liked
| more than Git Extensions' Commit view.
|
| 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/...
| IshKebab wrote:
| It's pretty good but also _really_ slow. I never found one
| better than GitX, but that was in the days before IDEs had Git
| support built in. Now they do it doesn 't really make sense to
| use a separate program IMO.
|
| These days I use VSCode and the Git Graph extension.
| nice_byte wrote:
| the only good git GUI that exists is Fork. Unfortunately, it
| doesn't run natively on Linux, although some people have had luck
| running it under Wine.
|
| 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?
| WolfeReader wrote:
| As much as I heartily disagree with most of what you wrote -
| and seeing all the downvotes, I'm not the only one - there is a
| nugget of truth in what you wrote, which answers a lot of your
| complaints.
|
| "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.
| krapht wrote:
| > 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+.
|
| 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>.
| 1718627440 wrote:
| The speed change you see is not due to raw input speed, but
| do to eliminating a context switch in the brain. I thinking
| I want to see X and already seeing it on the screen.
| nice_byte wrote:
| > 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+.
|
| 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 :-)
| CamJN wrote:
| Tower is also very good. Probably just due to having used it
| more, I prefer it over Fork, but I can get by if I have to use
| a computer not licensed for Tower.
| submeta wrote:
| Lazygit, WezTerm, NeoVim, Yazi (TUI file manager) are a fantastic
| combination! I have a tmuxniator config file for every project I
| work on. And open a tab in WezTerm, run ,,mx projectname", it
| opens a split for Yazi, one for Lazygit, one for neovim, and one
| for my agentic coding tool. Lovely setup, super fast, all in the
| terminal.
| bdewberry wrote:
| Simple, Clean, CLI, Vim navigation
|
| Lazy git checks off a lot of boxes. Easy tool to adopt to speed
| up and simplify your git workflow
| nicois wrote:
| A large percentage of git users are unaware of git-absorb
| (https://github.com/tummychow/git-absorb). This complements just
| about any git flow, vastly reducing the pain of realising you
| want to amend your staged changes into multiple commits. This
| sits well alongside many TUIs and other tools, most of which do
| not offer any similar capability.
| skydhash wrote:
| I see the usefulness. But my client is magit, and committing
| and rebasing are so quick that this will reduce perhaps 30
| seconds to one minute to my workflow. And I do not like most
| rust tools, because they're too dependency heavy.
| kccqzy wrote:
| Definitely. The instant fixup feature is just three
| keystrokes away (s c F). The only thing this helps is when
| you don't want to spend the extra brain cycles to figure out
| which commit to fixup on.
| 1718627440 wrote:
| The task that absorb speeds up is finding the commit where
| each hunk was last changed. The actual committing and
| rebaseing is still basically the same.
| skydhash wrote:
| Git blame using `M-x vc-annotate` with Emacs. But If I have
| a clean PR that usually means one to three commits (If it's
| not a big refactoring). So the whole point become moot. In
| magit, if you create a fixup or a squash commit, it will
| present you with the log to select the target.
| 1718627440 wrote:
| It's in the GNU/Debian repo and I guess in a lot of other
| distros as well.
| imiric wrote:
| I gave it a try a few months ago, and wasn't impressed. About a
| quarter of the time it got confused about the commit it should
| squash into, and left the repo in a half-applied state. This
| inconsistency was enough for me to not trust it when it did
| work, so I stopped using it.
|
| 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.
| jannniii wrote:
| Yes! Godspeed to lazygit!
|
| Really happy to see it featured here, I became a convert couple
| of years ago after switching to Astronvim (lazyvim is bundled
| with it).
| user432678 wrote:
| Maybe one day, but after almost 15 years of using handful of git
| aliases I just can't switch to anything else.
| xeromal wrote:
| I'm stuck on a mac these days and I miss Git Extensions, my
| favorite Windows git UI
| piskov wrote:
| Git Tower is the best native UI client
| mariusor wrote:
| I still prefer tig[1]. It has probably less features, but also a
| less cluttered UI and slightly faster interface.
|
| 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/
| rckt wrote:
| Personally I just couldn't see all the extra layers as
| comfortable tools. It's a very rare thing that I need to see
| branches, relation between them etc. Using cli has always been
| the most reliable and simple way for me.The only git tool I need
| apart from cli is a convenient conflict resolver.
| Terr_ wrote:
| Yeah: Most use-cases for me split into:
|
| 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.
| _--__--__ wrote:
| Lazygit is the only way I review PRs these days because it is
| trivial to step through a file commit by commit when that is
| necessary (which maybe says something about the quality of the
| PRs I'm reviewing...). They also won me over by using Legend of
| the Galactic Heroes references in the github readme gifs.
| _blk wrote:
| Maybe I missed it but I couldn't find where to install it from
| and autocomplete doesn't resolve to a debian package either...
|
| 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/ ```
| jmkmay wrote:
| Something not mentioned in the article which has changed the way
| I interact with git repos (and the reason I will never not use
| LazyVim until something better comes along) is just how well the
| system plays with tmux floating panes.
|
| 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.
| notpublic wrote:
| Indeed! I just found out about tmux display-popup recently.
| # ~/.tmux.conf bind-key C-g display-popup -E -d
| "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit"
|
| Then, in tmux: ctrl-b ctrl-g will open a popup
| window with lazygit q to quit
| kazinator wrote:
| "git gui" is not just a wrapper for commands; it has usefully
| different workflows.
|
| 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.
| 1718627440 wrote:
| > For instance, you can visually select a range of lines in a
| file, and stage those lines.
|
| Isn't this the standard for every Git GUI? Are there people who
| use a GUI that can't do that?
| kazinator wrote:
| [delayed]
| thdhhghgbhy wrote:
| lazygit is too slow at patching big files. If performance ever
| improves I'll come back from fugitive.
| rcarmo wrote:
| After a short stint when I had to do dozens of small edits to
| files, this became something I use every day (and I am the sort
| of person who types git commands by choice, even inside VS
| Code...)
| fngjdflmdflg wrote:
| I've found the built in gitk is pretty good for some GUI tasks.
| If I want to view the sate of some file at a given commit, it's
| easier to navigate using that rather than going through git log,
| find and copy the commit, git show, paste, copy the file path.
| GitHub desktop didn't seem to have this feature last I checked,
| even though the GitHub web viewer does.
| keyle wrote:
| Lazygit is great, I use it all the time for straight forward git-
| fu.
|
| 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
___________________________________________________________________
(page generated 2025-11-10 23:00 UTC)