12 ms·

The lazy Git UI you didn't know you need

436 points by linhns 11mo ago

varunramesh 11mo ago
I use lazygit when I want to stage specific lines rather than an entire file.
- unixplumber 11mo ago
  I use the CLI git to stage lines. Use `git add -p` to add only the lines you want to commit with your chosen text editor.
  - sevenseacat 11mo ago
    This is literally the only way I stage file changes. I want to see and approve everything that goes in.
magdyks 11mo ago
lazygit rules!
aeve890 11mo ago
I'd recommend lazydocker, from the same author IIRC. Awesome TUI.
tcoff91 11mo ago
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 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 https://github.com/julienvincent/hunk.nvim Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts 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 11mo ago
  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 11mo ago
    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.
  - muti 11mo ago
    Are you looking for solutions within git or jj? 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 https://git-scm.com/book/en/v2/Git-Tools-Rerere
  - wredcoll 11mo ago
    I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
    - __float 11mo ago
      I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight. A tool like https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.
Zambyte 11mo ago
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 11mo ago
  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 11mo ago
    You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.
    - Zambyte 11mo ago
      Or the shorthand: jj ci -i 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.
    - IshKebab 11mo ago
      With git I can stage lines right in my IDE, no messing around in shitty TUIs.
      - Zambyte 11mo ago
        https://jj-vcs.github.io/jj/latest/config/ https://jj-vcs.github.io/jj/latest/config/ ctrl+f "tool"
prmph 11mo ago
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 11mo ago
  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.
  - Quekid5 11mo ago
    Magit[0] is so good that I haven't felt any real need to use jj... yet. I'm sure I'll switch if it gets emacs integration of a similar level to magit, but the one I tried[1] isn't quite there yet. [0] Well, plus git-mediate for solving conflicts [1] https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el
    - abathologist 11mo ago
      Same. I have not been able to find an explanation of anything jj supports that I don't have already with magit, but I am open to learning :)
      - Quekid5 11mo ago
        I think the big thing (potentially, for me) is the ability to postpone conflict resolution during a rebase. That can be quite painful in regular old git, but git-mediate helps make that less painful in practice in my particular situation and workflow. We'll see once better non-cli UX appears. I'm low-key excited for what could be possible in this space.
nice_byte 11mo ago
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 11mo ago
  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 11mo ago
    > 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>.
submeta 11mo ago
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 11mo ago
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 11mo ago
A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/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 11mo ago
  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 11mo ago
    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 11mo ago
    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 11mo ago
      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.
      - gpderetta 11mo ago
        Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
jannniii 11mo ago
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 11mo ago
Maybe one day, but after almost 15 years of using handful of git aliases I just can’t switch to anything else.
xeromal 11mo ago
I'm stuck on a mac these days and I miss Git Extensions, my favorite Windows git UI
- piskov 11mo ago
  Git Tower is the best native UI client
- alwillis 11mo ago
  There are several really good Git clients for macOS: 1. Fork: https://git-fork.com https://git-fork.com 2. Kaleidoscope: https://kaleidoscope.app https://kaleidoscope.app 3. GitUp: https://gitup.co https://gitup.co 4. Tower: https://www.git-tower.com/mac https://www.git-tower.com/mac
  - glenneroo 11mo ago
    SourceTree also isn't too shabby, though the interface is slightly different than the Windows version (for whatever reason).
mariusor 11mo ago
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/ https://jonas.github.io/tig/
- petepete 11mo ago
  Me too, it’s been my tool of choice for staging hunks for more than 15 years now.
  - johnisgood 11mo ago
    For that, I use git-cola... for some reason. Even though I live in the terminal.
    - mariusor 11mo ago
      Oh, I didn't know it. It looks pretty useful, but it requires more mouse usage than I'd like and its window is not very well suited for tiled window managers straight out of the box.
      - johnisgood 11mo ago
        Yeah I have a rule in my i3 config so it gets focused and fullscreen. It does require mouse usage, which is why I wonder why I like it over say, lazygit. I may switch, but yeah, thought one should know of its existence, it is a cool piece of software, too.
rckt 11mo ago
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_ 11mo ago
  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.
- Izkata 11mo ago
  > It's a very rare thing that I need to see branches, relation between them etc. 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.
_--__--__ 11mo ago
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.
- jesseduffield 11mo ago
  Glad somebody got the reference!
_blk 11mo ago
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#installation 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/latest 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${LAZYGIT_VERSION}/lazygit_${LAZYGIT_VERSION}_Linux_x86_64.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 11mo ago
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 11mo ago
  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
  - jmkmay 11mo ago
    Pretty much my config exactly. I make mine a bit bigger tho: bind-key -n C-g display-popup -E -w 90% -h 80% -T "LazyGit" -d "#{pane_current_path}" "lazygit"
- witcher 11mo ago
  (author of the blog post here) 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!
kazinator 11mo ago
"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 11mo ago
  > 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 11mo ago
    No idea; I don't know every git gui; I'm talking about that Tcl/Tk thing that is literally run with "git gui". 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).
- witcher 11mo ago
  (author of the blog post here) 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).
thdhhghgbhy 11mo ago
lazygit is too slow at patching big files. If performance ever improves I'll come back from fugitive.
rcarmo 11mo ago
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 11mo ago
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 11mo ago
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 https://git-fork.com
- robin_reala 11mo ago
  To be clear, there isn’t a free version. There’s a cost-less download that’s meant for evaluation purposes, with the goal of paying them if you like it and find yourself using it long-term. 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.
- gpderetta 11mo ago
  --force-with-lease should be safer.
  - witcher 11mo ago
    force with lease has been used in lazgit already AFAIK, see: https://github.com/jesseduffield/lazygit/discussions/4068#discussioncomment-11347082 https://github.com/jesseduffield/lazygit/discussions/4068#di...
    - gpderetta 11mo ago
      "it is our policy that if something is already configurable in git, we don't add the same option again in lazygit" This seems a very solid rule.
insin 11mo ago
In the example of how they were removing specific lines from the previous commit, git gui had a way to do that instead of copying the diff lines and manually editing them back into the code: 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.
imiric 11mo ago
Am I the only one who simply doesn't mind Git's CLI? 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 https://github.com/mroth/scmpuff [2]: https://github.com/dandavison/delta https://github.com/dandavison/delta
- sublinear 11mo ago
  I completely agree, and I would add that in just about any dev role beyond being a junior it's so common to need to work efficiently without much of a dev environment anyway. There's just no point in fighting this battle. I will admit it's sometimes nice to have fancy tools, but they're just that. I don't get the need to make a hobby out of it when there's so much other stuff to do.
- tcoff91 11mo ago
  There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.
  - imiric 11mo ago
    Yeah, I disagree. I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers. A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.
rr808 11mo ago
Intellij is so much better than command line now, I can't imagine going back.
- glenneroo 11mo ago
  Well to be fair, anything is better than the CLI (unless you are a masochist ;)
promiseofbeans 11mo ago
People often avoid it because of the name, but Github desktop is pretty amazing. It works great with all git repos (including ones not on Github), and makes it super easy to amend commits and cherry-pick files/lines to include. Everything has handy names, and all the complex operations have text explaining what they do. GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired, but it's already 1000 times better than the git cli. Whenever I have someone who hasn't used git before joining a project, I always get them to use GH Desktop - it's easier for them to understand what's happening, and reduces the messes they cause compared to running random git commands from stack overflow.
- ramraj07 11mo ago
  Seconding GHD. They have added features very slowly, very thoughtfully; HN tends towards experts (or at least people who think they are). I am aware that I'm NOT good with git. I will never do anything that has "hard" or "rebase" in it without spending 20 minutes making sure its what I want to do. Unfortunately I have seen way too many semi junior engineers who think they're git lords who force push bad histories and ruin our git repo. I tend to suggest strongly that people should use github desktop if they are in my team though very few people take up that suggestion :)
  - skydhash 11mo ago
    It's very hard to destroy things with git. Every action is stored with the reflog. Then also, in a team setting, you should want the copy on the forge to have protected branches so that no one push (or force push) on them.
- jayd16 11mo ago
  > GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired I think that's more of the reason why people avoid it.
- stavros 11mo ago
  > it's already 1000 times better than the git cli Sure, but that's such a low bar, that everything clears it.
avtar 11mo ago
No one's mentioned Gitu yet but it's a pretty nice client https://github.com/altsem/gitu https://github.com/altsem/gitu
elias1233 11mo ago
The git integration in VS Code has gotten really good lately. It has the commit graph, with cherry picking, worktrees, stashes and a very nicely integrated merge editor and rebasing, along with all the common commands. Also staging individual sections and lines visually, which I use daily
thetyster 11mo ago
Perhaps I am a simpleton, but Tim Popes vim-fugitive has always been enough for me.
eulgro 11mo ago
Top things I love with lazygit: - Patching with <C-p>, easily the best feature. With a few keystrokes I can revert or move lines from any commit. - Amend any commit directly instead of fixup + rebase. - Single line hunk manipulation. - Integration with difftastic for semantic diffs.
EMM_386 11mo ago
VS Code is free, cross-platform, many people already use it, and has a very good GUI interface for git. It can easily do all the common workflows. I mainly use the CLI but if I already have a project open in VS Code I'll just do it in the GUI because it's actually faster in many cases and sometimes a bit more intuitive.
- scuff3d 11mo ago
  But then you have to use VSCode, and that's never a good thing.
  - hu3 11mo ago
    why is that never not a good thing to you?
- witcher 11mo ago
  (author of the blog post) Yes, I think it's a reasonable option if you use vscode on all your dev machines. We discussed this in another thread: https://news.ycombinator.com/item?id=45898167 https://news.ycombinator.com/item?id=45898167
brandon_bot 11mo ago
I was first convinced to try Lazygit after reading https://jesseduffield.com/Lazygit-5-Years-On/#weighing-in-on-the-cli-ui-debate https://jesseduffield.com/Lazygit-5-Years-On/#weighing-in-on... (written by Lazygit's creator). Haven't regretted it at all; the tool is a pleasure to use due to its great design decisions. Contributing back to the codebase is also quite straightforward.
zmmmmm 11mo ago
And I'm still just using tig [0]. I miss a few of the more fancy features but it's simple and reliable and compiles everywhere I need. [0] https://jonas.github.io/tig/ https://jonas.github.io/tig/
scotty79 11mo ago
After years of using git I got back to svn. Svn has one great feature, you can checkout (clone) repo partially. This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want. I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches. I'm not sure what I would prefer for a team project. I'm sure svn got decent merging.
- jeroenhd 11mo ago
  > I'm sure svn got decent merging. That's definitely not my experience. SVN has merging, but I've found it extremely frustrating in a team context.
  - scotty79 11mo ago
    When did you experience it last time? I remember it being bad, but it was before git was created.
    - jeroenhd 11mo ago
      Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.
- unixplumber 11mo ago
  One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
- alwillis 11mo ago
  > After years of using git I got back to svn You get the best of both worlds--a sane set of commands and a distributed version control system--by using Mercurial [1]. Checking Status: SVN: svn status Mercurial: hg status Adding Files: SVN: svn add <filename> Mercurial: hg add <filename> Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository) Deleting/Removing Files: SVN: svn delete <filename> or svn remove <filename> Mercurial: hg remove <filename> or hg rm <filename> Viewing History: SVN: svn log Mercurial: hg log Viewing Differences: SVN: svn diff Mercurial: hg diff Branching: SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository) Mercurial: hg branch <branchname> (creates a new named branch within the repository) Reverting Changes: SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts) Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit) [1]: https://www.mercurial-scm.org https://www.mercurial-scm.org
grogenaut 11mo ago
I prefer to just voice to text to an ai and have it do git operations for me. Either that or ctrl-r seem to be a great set of UI
lf-non 11mo ago
For folks looking for a GUI tool, SourceGit is quite nice. Written in C#, cross-platform (I have only used it on linux) and a cleanly-designed conventional ui that doesn't aspire to radically alter your workflow. https://github.com/sourcegit-scm/sourcegit https://github.com/sourcegit-scm/sourcegit
stevoski 11mo ago
Anyone used GitKraken? I haven’t, but for reasons, I’m interested to hear about your experience with it.
- korm 11mo ago
  Gitkraken is the best, and I can't believe anyone would voluntarily use Sourcetree over it. I've used gitkraken for over 9 years and it's great for both newbies and pros. It completely solves the problem with new or intermediate devs, who are not used to working in a sizable team, constantly needing hand-holding. Lots of people resist adopting it at first, but not one has regretted it so far. It usually goes like this: 1. "No I won't use it, the terminal is better" 2. Mess up 3. Finally give gitkraken a serious try 4. Realize they didn't really know git
- gfna 11mo ago
  Been using gitkraken for ages and still like it, but they do make it harder and harder to like every update. The enshittification seems to have started and every update seems to bring more and more ai features, and pushing more ”cloud” features as well
lionkor 11mo ago
If you're on Windows and you like the git CLI, try GitExtensions. It maps pretty much 1-to-1 to the git CLI and is still discoverable.
apple1417 11mo ago
I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them. Currently the best workflow I've worked out is just a plain git log --oneline --graph -- <dir> Followed by showing the specific commits. But this doesn't work so well with MRs that touched many files across different dirs. Anyone have suggestions for tools that might handle this better?
opello 11mo ago
> This site was paused as it reached its usage limits. https://web.archive.org/web/20251111071832/https://www.bwplotka.dev/2025/lazygit/ https://web.archive.org/web/20251111071832/https://www.bwplo...
- witcher 11mo ago
  Should be now fixed, 6k views was too much for a free tier! Thanks for archive link
  - throw14082020 11mo ago
    You should try cloudflare. 6k views is nothing on the free tier. Shocking to see your website taken down for 6k views Btw it's down again
    - witcher 11mo ago
      Makes sense, thanks!
globular-toast 11mo ago
I'm the "git guy" at every place I work and I don't touch the git CLI. Been using Magit for 15 years now. I just don't think a CLI is a good interface for state mutation. CLIs are perfect for functional interfaces, like grep, sed etc. But I think they are very hard to get right when side effects are in play. Really basic things like mkdir and rm are ok, but when you have enormously powerful things like git rebase I find it difficult to keep track of what's going on. I wonder what a more functional Unix would look like... Instead of mkdir just write to any path, instead of rm just overwrite a path with nothing, maybe we'd accept that mv would be implemented as "porcelain". The balance I think is keeping a lid on how complex that porcelain can become, and git has way overstepped the mark. So I prefer GUI/TUI interfaces for mutation, and Emacs is the best there is for building those.
deleted 11mo ago
[deleted]
detectivestory 11mo ago
My current setup is just a few alias commands and I use gitin instead of "git log". I really wish that tool was still in development because it provides a really nice minimalist design for exploring git repos: https://github.com/isacikgoz/gitin https://github.com/isacikgoz/gitin
fergonco 11mo ago
I have some bash_aliases and scripts. The king of all alias is fixup, which commits everything and fixes up the commit with the previous one. Another script just goes over the changes and allows me to add/skip/restore. Then I can pipe the log to another script that will analyze tags and tell me what is not yet in prod. cli is hard... but it composes. I want to know that CLI as well as possible. And I don't want to start from scratch each few years with a new UI / concept.
tanepiper 11mo ago
For some reason it shows half the text in English and half in Dutch
Jianghong94 11mo ago
Wait, no one mentions the default JetBrains IDE git UI? I mean, I get it if you're working from another IDE/text editor that doesn't have good git UI support out of the box, but JB's git UI is reasonably good enough that I don't want anything else. Things that I use (and I like): 1. quick checkout to another branch and automatically stash and unstash your local changes; when I just need to inspect code elsewhere I find it really useful. My changes are small so I can always remember to stash them later; 2. compare branch/commit etc via UI; again I know you can do that in git diff, but then you would need to know the command and the commit SHA to compare; in UI it comes in really handy, just select the branch or commits you want to compare and that's it. I've seen my coworkers trying to come up with the command and I just say: use IDE and a couple of clicks they got it working. 3. filter commits by user and by folder.
- brianpan 11mo ago
  The diffs are the biggest reason I use it (beside the 3-way diff, I can't live without: blame, optimize imports, all the editor functions inside the diff, diff files/commits/branches). Beyond that: separating into change lists (staging changes by line inside a file) and the graphical presentation and filtering of the commit history (highlighting what commits are in/out of your branch, show the git history of a section or line of code, show repo files at a commit)
- plonq 11mo ago
  100%. One big benefit of IDE integration is that it’s the same editor. Same keybindings, same syntax highlighting, etc.
- witcher 11mo ago
  (author of the blog here) That's a great point. I should have mention the IDE Git UIs, def a nice option and sounds like the JB one works well for you! I do use it heavily for "annotating git blame"! I've never consider using JB Git UI fully mainly because of the point made earlier, so stability (https://news.ycombinator.com/item?id=45898089 https://news.ycombinator.com/item?id=45898089). Once you learn, especially visually, you don't want cosmetic changes. IDEs change yearly to stay "consistent". Another point is portability. E.g. I didn't want to pay for personal use of JB (so rare case), so I have to use different IDE. Separate tools (especially free and OSS) is a big advantage. Not mentioning ability to use it on remote shells or different machines! lazy git offers 1, but 2 and 3 points are interesting. Wonder if there's an easy way to compare commits and filter commits by user and folder in lazygit. (: EDIT: Actually, I also use JB for conflict resolutions ;P so not entirely 100% lazygit flow.
santiagobasulto 11mo ago
Off-topic: but the README of lazygit is awful with all those sponsors at the top. I hope Github comes up with a better way to list sponsors that favors developers and allows them to exclude them from the README. https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit
fmoralesc 11mo ago
I use lazygit in neovim through the snacks plugin: https://github.com/folke/snacks.nvim/blob/main/docs/lazygit.md https://github.com/folke/snacks.nvim/blob/main/docs/lazygit.... It works really nicely, without any fuss.
gwbas1c 11mo ago
I just took lazygit for a spin: In general, the tool looks cool. It also looks like it takes time to learn; but if you find it useful, it's probably worth it taking the time to learn. There were two blockers for me: 1: I can't free-form select text with a mouse like a can in a terminal. (I honestly haven't used a TUI since the 1990s.) I frequently copy bits of branch names from the terminal, so this was a big deal for me. There is a way to "disable" the mouse in lazygit, which then allows copy & paste; but as I prefer to learn a program with point & click, it's a non-starter for me. 2: A lot of this functionality is built into Visual Studio for me. I use a mix of Visual Studio's point & click with git, and then the git command-line: Whichever is easiest for the specific task I'm doing. It just takes a bit more exploration in Visual Studio to find this functionality, as opposed to it being front and center when starting lazygit.
- lordnacho 11mo ago
  If you run it in a tmux, you can do "set -g mouse on" in your config and then just select whatever you want.
  - gwbas1c 11mo ago
    TMux doesn't run on Windows. (Kinda implied, because I stated I use Visual Studio.)
- witcher 11mo ago
  (author of the blog post here) Fully agree! 1. Yes, it's been a frustration initially, but it has a nice benefit - it forces you to use native features (e.g. patch based copy/reset). Apparently it's on the radar, but not implemented yet: https://github.com/jesseduffield/lazygit/issues/4365#issuecomment-2703252685 https://github.com/jesseduffield/lazygit/issues/4365#issueco... 2. Yes, see https://news.ycombinator.com/item?id=45898167 https://news.ycombinator.com/item?id=45898167 discussion. Using IDE is great if all your machines has this IDE installed (and GUI in general). The stability (graphical layout) is likely changing often though.

436 points by linhns 11mo ago

varunramesh 11mo ago

I use lazygit when I want to stage specific lines rather than an entire file.

unixplumber 11mo ago
I use the CLI git to stage lines. Use `git add -p` to add only the lines you want to commit with your chosen text editor.
- sevenseacat 11mo ago
  This is literally the only way I stage file changes. I want to see and approve everything that goes in.

magdyks 11mo ago

lazygit rules!

aeve890 11mo ago

I'd recommend lazydocker, from the same author IIRC. Awesome TUI.

tcoff91 11mo ago

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 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 https://github.com/julienvincent/hunk.nvim Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts 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 11mo ago
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 11mo ago
  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.
- muti 11mo ago
  Are you looking for solutions within git or jj? 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 https://git-scm.com/book/en/v2/Git-Tools-Rerere
- wredcoll 11mo ago
  I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
  - __float 11mo ago
    I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight. A tool like https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.

Zambyte 11mo ago

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 11mo ago
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 11mo ago
  You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.
  - Zambyte 11mo ago
    Or the shorthand: jj ci -i 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.
  - IshKebab 11mo ago
    With git I can stage lines right in my IDE, no messing around in shitty TUIs.
    - Zambyte 11mo ago
      https://jj-vcs.github.io/jj/latest/config/ https://jj-vcs.github.io/jj/latest/config/ ctrl+f "tool"

prmph 11mo ago

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 11mo ago
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.
- Quekid5 11mo ago
  Magit[0] is so good that I haven't felt any real need to use jj... yet. I'm sure I'll switch if it gets emacs integration of a similar level to magit, but the one I tried[1] isn't quite there yet. [0] Well, plus git-mediate for solving conflicts [1] https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el
  - abathologist 11mo ago
    Same. I have not been able to find an explanation of anything jj supports that I don't have already with magit, but I am open to learning :)
    - Quekid5 11mo ago
      I think the big thing (potentially, for me) is the ability to postpone conflict resolution during a rebase. That can be quite painful in regular old git, but git-mediate helps make that less painful in practice in my particular situation and workflow. We'll see once better non-cli UX appears. I'm low-key excited for what could be possible in this space.

nice_byte 11mo ago

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 11mo ago
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 11mo ago
  > 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>.

submeta 11mo ago

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 11mo ago

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 11mo ago

A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/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 11mo ago
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 11mo ago
  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 11mo ago
  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 11mo ago
    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.
    - gpderetta 11mo ago
      Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.

jannniii 11mo ago

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 11mo ago

Maybe one day, but after almost 15 years of using handful of git aliases I just can’t switch to anything else.

xeromal 11mo ago

I'm stuck on a mac these days and I miss Git Extensions, my favorite Windows git UI

piskov 11mo ago
Git Tower is the best native UI client
alwillis 11mo ago
There are several really good Git clients for macOS: 1. Fork: https://git-fork.com https://git-fork.com 2. Kaleidoscope: https://kaleidoscope.app https://kaleidoscope.app 3. GitUp: https://gitup.co https://gitup.co 4. Tower: https://www.git-tower.com/mac https://www.git-tower.com/mac
- glenneroo 11mo ago
  SourceTree also isn't too shabby, though the interface is slightly different than the Windows version (for whatever reason).

mariusor 11mo ago

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/ https://jonas.github.io/tig/

petepete 11mo ago
Me too, it’s been my tool of choice for staging hunks for more than 15 years now.
- johnisgood 11mo ago
  For that, I use git-cola... for some reason. Even though I live in the terminal.
  - mariusor 11mo ago
    Oh, I didn't know it. It looks pretty useful, but it requires more mouse usage than I'd like and its window is not very well suited for tiled window managers straight out of the box.
    - johnisgood 11mo ago
      Yeah I have a rule in my i3 config so it gets focused and fullscreen. It does require mouse usage, which is why I wonder why I like it over say, lazygit. I may switch, but yeah, thought one should know of its existence, it is a cool piece of software, too.

rckt 11mo ago

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_ 11mo ago
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.
Izkata 11mo ago
> It's a very rare thing that I need to see branches, relation between them etc. 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.

_--__--__ 11mo ago

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.

jesseduffield 11mo ago
Glad somebody got the reference!

_blk 11mo ago

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#installation 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/latest 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${LAZYGIT_VERSION}/lazygit_${LAZYGIT_VERSION}_Linux_x86_64.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 11mo ago

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 11mo ago
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
- jmkmay 11mo ago
  Pretty much my config exactly. I make mine a bit bigger tho: bind-key -n C-g display-popup -E -w 90% -h 80% -T "LazyGit" -d "#{pane_current_path}" "lazygit"
witcher 11mo ago
(author of the blog post here) 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!

kazinator 11mo ago

"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 11mo ago
> 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 11mo ago
  No idea; I don't know every git gui; I'm talking about that Tcl/Tk thing that is literally run with "git gui". 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).
witcher 11mo ago
(author of the blog post here) 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).

thdhhghgbhy 11mo ago

lazygit is too slow at patching big files. If performance ever improves I'll come back from fugitive.

rcarmo 11mo ago

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 11mo ago

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 11mo ago

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 https://git-fork.com

robin_reala 11mo ago
To be clear, there isn’t a free version. There’s a cost-less download that’s meant for evaluation purposes, with the goal of paying them if you like it and find yourself using it long-term. 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.
gpderetta 11mo ago
--force-with-lease should be safer.
- witcher 11mo ago
  force with lease has been used in lazgit already AFAIK, see: https://github.com/jesseduffield/lazygit/discussions/4068#discussioncomment-11347082 https://github.com/jesseduffield/lazygit/discussions/4068#di...
  - gpderetta 11mo ago
    "it is our policy that if something is already configurable in git, we don't add the same option again in lazygit" This seems a very solid rule.

insin 11mo ago

In the example of how they were removing specific lines from the previous commit, git gui had a way to do that instead of copying the diff lines and manually editing them back into the code: 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.

imiric 11mo ago

Am I the only one who simply doesn't mind Git's CLI? 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 https://github.com/mroth/scmpuff [2]: https://github.com/dandavison/delta https://github.com/dandavison/delta

sublinear 11mo ago
I completely agree, and I would add that in just about any dev role beyond being a junior it's so common to need to work efficiently without much of a dev environment anyway. There's just no point in fighting this battle. I will admit it's sometimes nice to have fancy tools, but they're just that. I don't get the need to make a hobby out of it when there's so much other stuff to do.
tcoff91 11mo ago
There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.
- imiric 11mo ago
  Yeah, I disagree. I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers. A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.

rr808 11mo ago

Intellij is so much better than command line now, I can't imagine going back.

glenneroo 11mo ago
Well to be fair, anything is better than the CLI (unless you are a masochist ;)

promiseofbeans 11mo ago

People often avoid it because of the name, but Github desktop is pretty amazing. It works great with all git repos (including ones not on Github), and makes it super easy to amend commits and cherry-pick files/lines to include. Everything has handy names, and all the complex operations have text explaining what they do. GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired, but it's already 1000 times better than the git cli. Whenever I have someone who hasn't used git before joining a project, I always get them to use GH Desktop - it's easier for them to understand what's happening, and reduces the messes they cause compared to running random git commands from stack overflow.

ramraj07 11mo ago
Seconding GHD. They have added features very slowly, very thoughtfully; HN tends towards experts (or at least people who think they are). I am aware that I'm NOT good with git. I will never do anything that has "hard" or "rebase" in it without spending 20 minutes making sure its what I want to do. Unfortunately I have seen way too many semi junior engineers who think they're git lords who force push bad histories and ruin our git repo. I tend to suggest strongly that people should use github desktop if they are in my team though very few people take up that suggestion :)
- skydhash 11mo ago
  It's very hard to destroy things with git. Every action is stored with the reflog. Then also, in a team setting, you should want the copy on the forge to have protected branches so that no one push (or force push) on them.
jayd16 11mo ago
> GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired I think that's more of the reason why people avoid it.
stavros 11mo ago
> it's already 1000 times better than the git cli Sure, but that's such a low bar, that everything clears it.

avtar 11mo ago

No one's mentioned Gitu yet but it's a pretty nice client https://github.com/altsem/gitu https://github.com/altsem/gitu

elias1233 11mo ago

The git integration in VS Code has gotten really good lately. It has the commit graph, with cherry picking, worktrees, stashes and a very nicely integrated merge editor and rebasing, along with all the common commands. Also staging individual sections and lines visually, which I use daily

thetyster 11mo ago

Perhaps I am a simpleton, but Tim Popes vim-fugitive has always been enough for me.

eulgro 11mo ago

Top things I love with lazygit: - Patching with <C-p>, easily the best feature. With a few keystrokes I can revert or move lines from any commit. - Amend any commit directly instead of fixup + rebase. - Single line hunk manipulation. - Integration with difftastic for semantic diffs.

EMM_386 11mo ago

VS Code is free, cross-platform, many people already use it, and has a very good GUI interface for git. It can easily do all the common workflows. I mainly use the CLI but if I already have a project open in VS Code I'll just do it in the GUI because it's actually faster in many cases and sometimes a bit more intuitive.

scuff3d 11mo ago
But then you have to use VSCode, and that's never a good thing.
- hu3 11mo ago
  why is that never not a good thing to you?
witcher 11mo ago
(author of the blog post) Yes, I think it's a reasonable option if you use vscode on all your dev machines. We discussed this in another thread: https://news.ycombinator.com/item?id=45898167 https://news.ycombinator.com/item?id=45898167

brandon_bot 11mo ago

I was first convinced to try Lazygit after reading https://jesseduffield.com/Lazygit-5-Years-On/#weighing-in-on-the-cli-ui-debate https://jesseduffield.com/Lazygit-5-Years-On/#weighing-in-on... (written by Lazygit's creator). Haven't regretted it at all; the tool is a pleasure to use due to its great design decisions. Contributing back to the codebase is also quite straightforward.

zmmmmm 11mo ago

And I'm still just using tig [0]. I miss a few of the more fancy features but it's simple and reliable and compiles everywhere I need. [0] https://jonas.github.io/tig/ https://jonas.github.io/tig/

scotty79 11mo ago

After years of using git I got back to svn. Svn has one great feature, you can checkout (clone) repo partially. This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want. I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches. I'm not sure what I would prefer for a team project. I'm sure svn got decent merging.

jeroenhd 11mo ago
> I'm sure svn got decent merging. That's definitely not my experience. SVN has merging, but I've found it extremely frustrating in a team context.
- scotty79 11mo ago
  When did you experience it last time? I remember it being bad, but it was before git was created.
  - jeroenhd 11mo ago
    Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.
unixplumber 11mo ago
One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
alwillis 11mo ago
> After years of using git I got back to svn You get the best of both worlds--a sane set of commands and a distributed version control system--by using Mercurial [1]. Checking Status: SVN: svn status Mercurial: hg status Adding Files: SVN: svn add <filename> Mercurial: hg add <filename> Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository) Deleting/Removing Files: SVN: svn delete <filename> or svn remove <filename> Mercurial: hg remove <filename> or hg rm <filename> Viewing History: SVN: svn log Mercurial: hg log Viewing Differences: SVN: svn diff Mercurial: hg diff Branching: SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository) Mercurial: hg branch <branchname> (creates a new named branch within the repository) Reverting Changes: SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts) Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit) [1]: https://www.mercurial-scm.org https://www.mercurial-scm.org

grogenaut 11mo ago

I prefer to just voice to text to an ai and have it do git operations for me. Either that or ctrl-r seem to be a great set of UI

lf-non 11mo ago

For folks looking for a GUI tool, SourceGit is quite nice. Written in C#, cross-platform (I have only used it on linux) and a cleanly-designed conventional ui that doesn't aspire to radically alter your workflow. https://github.com/sourcegit-scm/sourcegit https://github.com/sourcegit-scm/sourcegit

stevoski 11mo ago

Anyone used GitKraken? I haven’t, but for reasons, I’m interested to hear about your experience with it.

korm 11mo ago
Gitkraken is the best, and I can't believe anyone would voluntarily use Sourcetree over it. I've used gitkraken for over 9 years and it's great for both newbies and pros. It completely solves the problem with new or intermediate devs, who are not used to working in a sizable team, constantly needing hand-holding. Lots of people resist adopting it at first, but not one has regretted it so far. It usually goes like this: 1. "No I won't use it, the terminal is better" 2. Mess up 3. Finally give gitkraken a serious try 4. Realize they didn't really know git
gfna 11mo ago
Been using gitkraken for ages and still like it, but they do make it harder and harder to like every update. The enshittification seems to have started and every update seems to bring more and more ai features, and pushing more ”cloud” features as well

lionkor 11mo ago

If you're on Windows and you like the git CLI, try GitExtensions. It maps pretty much 1-to-1 to the git CLI and is still discoverable.

apple1417 11mo ago

I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them. Currently the best workflow I've worked out is just a plain git log --oneline --graph -- <dir> Followed by showing the specific commits. But this doesn't work so well with MRs that touched many files across different dirs. Anyone have suggestions for tools that might handle this better?

opello 11mo ago

> This site was paused as it reached its usage limits. https://web.archive.org/web/20251111071832/https://www.bwplotka.dev/2025/lazygit/ https://web.archive.org/web/20251111071832/https://www.bwplo...

witcher 11mo ago
Should be now fixed, 6k views was too much for a free tier! Thanks for archive link
- throw14082020 11mo ago
  You should try cloudflare. 6k views is nothing on the free tier. Shocking to see your website taken down for 6k views Btw it's down again
  - witcher 11mo ago
    Makes sense, thanks!

globular-toast 11mo ago

I'm the "git guy" at every place I work and I don't touch the git CLI. Been using Magit for 15 years now. I just don't think a CLI is a good interface for state mutation. CLIs are perfect for functional interfaces, like grep, sed etc. But I think they are very hard to get right when side effects are in play. Really basic things like mkdir and rm are ok, but when you have enormously powerful things like git rebase I find it difficult to keep track of what's going on. I wonder what a more functional Unix would look like... Instead of mkdir just write to any path, instead of rm just overwrite a path with nothing, maybe we'd accept that mv would be implemented as "porcelain". The balance I think is keeping a lid on how complex that porcelain can become, and git has way overstepped the mark. So I prefer GUI/TUI interfaces for mutation, and Emacs is the best there is for building those.

deleted 11mo ago

[deleted]

detectivestory 11mo ago

My current setup is just a few alias commands and I use gitin instead of "git log". I really wish that tool was still in development because it provides a really nice minimalist design for exploring git repos: https://github.com/isacikgoz/gitin https://github.com/isacikgoz/gitin

fergonco 11mo ago

I have some bash_aliases and scripts. The king of all alias is fixup, which commits everything and fixes up the commit with the previous one. Another script just goes over the changes and allows me to add/skip/restore. Then I can pipe the log to another script that will analyze tags and tell me what is not yet in prod. cli is hard... but it composes. I want to know that CLI as well as possible. And I don't want to start from scratch each few years with a new UI / concept.

tanepiper 11mo ago

For some reason it shows half the text in English and half in Dutch

Jianghong94 11mo ago

Wait, no one mentions the default JetBrains IDE git UI? I mean, I get it if you're working from another IDE/text editor that doesn't have good git UI support out of the box, but JB's git UI is reasonably good enough that I don't want anything else. Things that I use (and I like): 1. quick checkout to another branch and automatically stash and unstash your local changes; when I just need to inspect code elsewhere I find it really useful. My changes are small so I can always remember to stash them later; 2. compare branch/commit etc via UI; again I know you can do that in git diff, but then you would need to know the command and the commit SHA to compare; in UI it comes in really handy, just select the branch or commits you want to compare and that's it. I've seen my coworkers trying to come up with the command and I just say: use IDE and a couple of clicks they got it working. 3. filter commits by user and by folder.

brianpan 11mo ago
The diffs are the biggest reason I use it (beside the 3-way diff, I can't live without: blame, optimize imports, all the editor functions inside the diff, diff files/commits/branches). Beyond that: separating into change lists (staging changes by line inside a file) and the graphical presentation and filtering of the commit history (highlighting what commits are in/out of your branch, show the git history of a section or line of code, show repo files at a commit)
plonq 11mo ago
100%. One big benefit of IDE integration is that it’s the same editor. Same keybindings, same syntax highlighting, etc.
witcher 11mo ago
(author of the blog here) That's a great point. I should have mention the IDE Git UIs, def a nice option and sounds like the JB one works well for you! I do use it heavily for "annotating git blame"! I've never consider using JB Git UI fully mainly because of the point made earlier, so stability (https://news.ycombinator.com/item?id=45898089 https://news.ycombinator.com/item?id=45898089). Once you learn, especially visually, you don't want cosmetic changes. IDEs change yearly to stay "consistent". Another point is portability. E.g. I didn't want to pay for personal use of JB (so rare case), so I have to use different IDE. Separate tools (especially free and OSS) is a big advantage. Not mentioning ability to use it on remote shells or different machines! lazy git offers 1, but 2 and 3 points are interesting. Wonder if there's an easy way to compare commits and filter commits by user and folder in lazygit. (: EDIT: Actually, I also use JB for conflict resolutions ;P so not entirely 100% lazygit flow.

santiagobasulto 11mo ago

Off-topic: but the README of lazygit is awful with all those sponsors at the top. I hope Github comes up with a better way to list sponsors that favors developers and allows them to exclude them from the README. https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit

fmoralesc 11mo ago

I use lazygit in neovim through the snacks plugin: https://github.com/folke/snacks.nvim/blob/main/docs/lazygit.md https://github.com/folke/snacks.nvim/blob/main/docs/lazygit.... It works really nicely, without any fuss.

gwbas1c 11mo ago

I just took lazygit for a spin: In general, the tool looks cool. It also looks like it takes time to learn; but if you find it useful, it's probably worth it taking the time to learn. There were two blockers for me: 1: I can't free-form select text with a mouse like a can in a terminal. (I honestly haven't used a TUI since the 1990s.) I frequently copy bits of branch names from the terminal, so this was a big deal for me. There is a way to "disable" the mouse in lazygit, which then allows copy & paste; but as I prefer to learn a program with point & click, it's a non-starter for me. 2: A lot of this functionality is built into Visual Studio for me. I use a mix of Visual Studio's point & click with git, and then the git command-line: Whichever is easiest for the specific task I'm doing. It just takes a bit more exploration in Visual Studio to find this functionality, as opposed to it being front and center when starting lazygit.

lordnacho 11mo ago
If you run it in a tmux, you can do "set -g mouse on" in your config and then just select whatever you want.
- gwbas1c 11mo ago
  TMux doesn't run on Windows. (Kinda implied, because I stated I use Visual Studio.)
witcher 11mo ago
(author of the blog post here) Fully agree! 1. Yes, it's been a frustration initially, but it has a nice benefit - it forces you to use native features (e.g. patch based copy/reset). Apparently it's on the radar, but not implemented yet: https://github.com/jesseduffield/lazygit/issues/4365#issuecomment-2703252685 https://github.com/jesseduffield/lazygit/issues/4365#issueco... 2. Yes, see https://news.ycombinator.com/item?id=45898167 https://news.ycombinator.com/item?id=45898167 discussion. Using IDE is great if all your machines has this IDE installed (and GUI in general). The stability (graphical layout) is likely changing often though.