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?
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.
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.
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.
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.
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.
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.
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.
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).
Big fan of sublime merge. I recommend it a lot to people who need to dip their toes in source control and want some layer of abstraction, but also want to feel like they’re connected to the underlying tool (git). Merge balances this very well.
I know a lot of devs hate on Perforce (and I am no exception), but I've grown to actually really like p4merge (the Perforce merge tool) for handling conflicts.
It's a bit of an odd one, and it has a bit of a learning curve, but it's free (as in beer), relatively easy to install, and seems to work well for me. I haven't found a FOSS tool that I like as much yet.
I love Tower and have paid for it for years. I can’t imagine using the git CLI now. GUIs were invented for a reason and the git CLI has terrible ergonomics and many ways to make costly mistakes.
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.
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.
If you don't mind a TUI, I've been very much enjoying gitui - in fact, this is the second time I've recommended it recently. Adding hunks and single lines is easy, and the various commands are all visible, so it lacks the usual TUI experience of "what key do I need again?"
Its good but actually a little slow at times. For a big repo, it feels like they're handling a few commands synchronously and it hits IDE performance, when they should really be showing some kind of async spinner and yielding so the rest of the IDE continues.
If you're down to try it, I actually think SmartGit is a similar style but ended up working better for the slightly more exotic things like submodules.
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.
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.
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.
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.
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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…)
"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.
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).
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.
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.
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.
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.
I can use the CLI, but magit is mostly CLI on steroids. All the information you could have accessed through the cli is quickly available, and they are active objects, meaning subsequent commands will take that into account. Any mutation is also available through quick keybindings as well.
The one thing that I truly like about Magit, and the builtin vc-mode, is that I can focus for a couple of hours on coding, then quickly create a serie of commits to capture that work. Like doing line art after sketching. I like when administrative work (filing patches under commits) is isolated from creative work (solving problems and designing practical solutions).
No - unless you took away my gitconfig, which is pretty big at this point. Though I guess that's mostly a time-saver. Even so, I've found most of the GUI tools to be confusing because it's hard to tell what they're actually doing under the hood.
I do use sublime merge at times though now - it's nice for [un]staging individual lines and for looking at some diffs. I also like git-foresta[1] more than log sometimes. I'll have to check out scmpuff - it should be easier than going through a patch add.
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.
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?
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.
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.
> 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>.
> 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 :-)
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.
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!
git rerere
https://git-scm.com/book/en/v2/Git-Tools-Rerere
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
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.
1 reply →
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.
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.
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
3 replies →
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.
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.
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.
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
2 replies →
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/...
Now I've got to mention Sublime Merge as my personal favorite: super fast, nice clean UI on all platforms, still maintained, single purchase license.
Big fan of sublime merge. I recommend it a lot to people who need to dip their toes in source control and want some layer of abstraction, but also want to feel like they’re connected to the underlying tool (git). Merge balances this very well.
I know a lot of devs hate on Perforce (and I am no exception), but I've grown to actually really like p4merge (the Perforce merge tool) for handling conflicts.
It's a bit of an odd one, and it has a bit of a learning curve, but it's free (as in beer), relatively easy to install, and seems to work well for me. I haven't found a FOSS tool that I like as much yet.
2 replies →
I find both Fork and Tower to be much better than SourceTree, have you only tried free tools?
I love Tower and have paid for it for years. I can’t imagine using the git CLI now. GUIs were invented for a reason and the git CLI has terrible ergonomics and many ways to make costly mistakes.
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.
3 replies →
I have dabbled in those tools. Still did not change my opinion.
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.
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,...
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.
If you don't mind a TUI, I've been very much enjoying gitui - in fact, this is the second time I've recommended it recently. Adding hunks and single lines is easy, and the various commands are all visible, so it lacks the usual TUI experience of "what key do I need again?"
Have you tried the Jetbrains IDE git client yet? It hits the perfect spot for me.
Its good but actually a little slow at times. For a big repo, it feels like they're handling a few commands synchronously and it hits IDE performance, when they should really be showing some kind of async spinner and yielding so the rest of the IDE continues.
If you're down to try it, I actually think SmartGit is a similar style but ended up working better for the slightly more exotic things like submodules.
Do you use the Mac or Windows version?
The Mac version
1 reply →
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.
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.
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.
You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.
1 reply →
In JJ you make a bunch of changes and then you split the commit into multiple commits.
This exact thing is quite literally one of jj’s flagship features: `jj split`.
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.
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 :)
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.
> 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.
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.
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.
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.
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.
1 reply →
to me this appears to be trading off a valid change log for neat naming ... i dont see why rewriting history is ever a good idea
It's in the GNU/Debian repo and I guess in a lot of other distros as well.
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.
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/
Me too, it’s been my tool of choice for staging hunks for more than 15 years now.
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.
But then you have to use VSCode, and that's never a good thing.
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.
Indeed! I just found out about tmux display-popup recently.
Then, in tmux:
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
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/
No one's mentioned Gitu yet but it's a pretty nice client https://github.com/altsem/gitu
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).
I was first convinced to try Lazygit after reading 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.
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
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.
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
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.
> 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.
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.
Perhaps I am a simpleton, but Tim Popes vim-fugitive has always been enough for me.
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…)
"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.
> 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?
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).
I'm stuck on a mac these days and I miss Git Extensions, my favorite Windows git UI
There are several really good Git clients for macOS:
1. Fork: https://git-fork.com
2. Kaleidoscope: https://kaleidoscope.app
3. GitUp: https://gitup.co
4. Tower: https://www.git-tower.com/mac
Git Tower is the best native UI client
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.
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.
Intellij is so much better than command line now, I can't imagine going back.
I'd recommend lazydocker, from the same author IIRC. Awesome TUI.
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.
Maybe one day, but after almost 15 years of using handful of git aliases I just can’t switch to anything else.
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
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.
I use lazygit when I want to stage specific lines rather than an entire file.
lazygit is too slow at patching big files. If performance ever improves I'll come back from fugitive.
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.
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
[2]: https://github.com/dandavison/delta
I can use the CLI, but magit is mostly CLI on steroids. All the information you could have accessed through the cli is quickly available, and they are active objects, meaning subsequent commands will take that into account. Any mutation is also available through quick keybindings as well.
The one thing that I truly like about Magit, and the builtin vc-mode, is that I can focus for a couple of hours on coding, then quickly create a serie of commits to capture that work. Like doing line art after sketching. I like when administrative work (filing patches under commits) is isolated from creative work (solving problems and designing practical solutions).
No - unless you took away my gitconfig, which is pretty big at this point. Though I guess that's mostly a time-saver. Even so, I've found most of the GUI tools to be confusing because it's hard to tell what they're actually doing under the hood.
I do use sublime merge at times though now - it's nice for [un]staging individual lines and for looking at some diffs. I also like git-foresta[1] more than log sometimes. I'll have to check out scmpuff - it should be easier than going through a patch add.
[1]: https://github.com/takaaki-kasai/git-foresta
There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.
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.
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/ ```
lazygit rules!
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?
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.
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.
> 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>.
1 reply →
> 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 :-)