7 ms·

Rebasing in Magit

224 points by ibobev 8mo ago

mschulze 8mo ago
I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using --onto, see https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_interesting_rebases https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_...) are a breeze with Magit. I can't remember the order of branches to use on the CLI, in Magit it's just "r s" basically. It's really magic.
- lambda 8mo ago
  Magit is absolutely the best Git GUI ever. Unfortunately, for most people the fact that it's part of Emacs is a blocker. And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit. So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.
  - troupo 8mo ago
    The best gut GUI is GitUp: https://gitup.co/ https://gitup.co/ Magit is not even close to be on the same level. Any insane operation you want at your fingertips.
    - deleted 8mo ago
      [deleted]
    - jbstack 8mo ago
      It's Mac-only. That's a pretty serious limitation for a modern Git tool.
    - MainlyMortal 8mo ago
      I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.
      - znpy 8mo ago
        > I don't even use a Mac any more after 20 years So the software is mac-only, you haven't used a mac in over 20 years so you haven't used this software and yet... you claim it's better than magit? i mean, it's very dishonest at best.
        troupo 8mo ago
        The claim was that its GUI is better than Magit's, following this claim: "Magit is absolutely the best Git GUI ever."
        lambda 8mo ago
        It may be prettier looking. I've seen many Git GUIs that are prettier than Magit. But none of them that I've tried have ever come close to the workflow. I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs. Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI". So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
        troupo 8mo ago
        > I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs. I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts. My most common workflow besides staging anything is (to make sure history is clean): - split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit) - move new commit up/down the branch (doesn't require interactive rebase in GitUp) - squash up/down (undo/redo from time to time) As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent > Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI". The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2] However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason. [1] I only have this blog post to confirm https://www.howardism.org/Technical/Emacs/magit-squashing.html https://www.howardism.org/Technical/Emacs/magit-squashing.ht... [2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.
    - ileonichwiesz 8mo ago
      Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?
      - troupo 8mo ago
        > Isn’t this just something that any IDE has built-in these days? In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too). Some of my idiosyncratic usage I developed with GitUp doesn't even exist in most (all?) Git tools: https://news.ycombinator.com/item?id=47329489 https://news.ycombinator.com/item?id=47329489 (see my most common workflow)
  - w4rh4wk5 8mo ago
    I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover.
    - zelphirkalt 8mo ago
      I am not someone to recommend VSCode, but if you are already using it, you could check out edamagit. I think in the Vim world there is also some equivalent.
    - MobileVet 8mo ago
      Run spacemacs in ‘evil mode’ so you can use Vim!
  - saila 8mo ago
    Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care). The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
    - hrmtst93837 8mo ago
      [flagged]
  - imiric 8mo ago
    Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit. Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command. This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
  - znpy 8mo ago
    > Unfortunately, for most people the fact that it's part of Emacs is a blocker. OT but i've learned the hard way not to push people into emacs. a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs . Reality is, i didn't want to have that role and that colleague wasn't interested in gnu emacs in the first place. That was a very stupid mistake on my side. Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances". Some people are intrigued, most other absolutely aren't... And it's fine.
    - kqr 8mo ago
      Surely the mistake here is conflating "learning Magit" with "learning Emacs"? I can run Java applications while knowing nearly nothing about the JVM. The same is true for applications based on Emacs.
      - steve1977 8mo ago
        One does not simply use Emacs.
        worik 8mo ago
        I simply used Emacs for 25 years, avoiding editing .emacs entirely Only in the past years have I started customizing it My attraction to Emacs is stability and I can use it in text or GUI mode. Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs
      - tsimionescu 8mo ago
        Magit is not an "application based on Emacs", it's an extremely powerful git plugin for someone who is already using Emacs. If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase. Even the fact that you'd have to learn Emacs' extremely idiosyncratic keyboard shortcuts, and even keyboard shortcut help (what do you mean "save is C-x C-s?" what does that even mean?) is a huge problem not worth the effort. And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.
  - publicdebates 8mo ago
    https://github.com/magit/magit/issues/3961 https://github.com/magit/magit/issues/3961
  - moritzwarhier 8mo ago
    Personally, I'm not a Git magician, but I prefer the Git CLI for most operations. Only exception is resolving conflicts. The most important point for every gut IDE integration to me is that it cleanly maps to the file system and CLI state.
    - mr_mitm 8mo ago
      Staging single lines or hunks is also much easier in a TUI/GUI. I wouldn't even know how to do it with just git.
      - stackbutterflow 8mo ago
        git add -p
        deleted 8mo ago
        [deleted]
        kirici 8mo ago
        Operates on hunks, which may at times be multiple lines that cannot be split further
        throw-the-towel 8mo ago
        You can edit a hunk with `e`. Clunky but it works.
        nothrabannosir 8mo ago
        In a conversation about magit, this is comparing jumping off a sidewalk to powered flight.
        yacin 8mo ago
        oftentimes splitting the hunks with `s` is enough.
  - badsectoracula 8mo ago
    > Magit is absolutely the best Git GUI ever. But it isn't graphical :-P. Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux. Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist). I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it. In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself). https://fuel-scm.org/fossil/index https://fuel-scm.org/fossil/index
  - 0x1ceb00da 8mo ago
    > Magit is absolutely the best Git GUI ever Not even close. Claude and codex are the best git gui.
- erksa 8mo ago
  Same, emacs being the barrier for most.
- jayd16 8mo ago
  What makes something easier in magit than, for example, SmartGit?
  - mschulze 8mo ago
    I haven't used SmartGit, so I can't really compare. I would single out the following for Magit: 1. Single key strokes for actions and toggles 2. Discoverability through "slide-ins" (TFA also explains this) For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do. So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2. If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts.
    - zelphirkalt 8mo ago
      I would also highlight that in Emacs magit one can always drop back to command line by pressing "!", which I do, when I don't know how to do something in Magit. Like "git submodule update --init --recursive".
  - plieber 8mo ago
    Magit feels very efficient to many developers because it is essentially a thin layer over Git itself. If you already know Git commands and work comfortably inside Emacs, Magit lets you trigger many operations extremely quickly using short key sequences. In that sense it is very close to the mental model of Git. However, that efficiency comes with a prerequisite: you need to remember commands, understand Git concepts well, and work inside a keyboard driven environment. SmartGit focuses on a different kind of efficiency. Instead of optimizing for memorizing commands, it optimizes for visual understanding and discoverability. Complex operations like rebasing, resolving conflicts, working with multiple repositories, or managing submodules become easier because the state of the repository is immediately visible and actions are guided. So the difference is less about what Git can do and more about how quickly a developer can understand and control what is happening. Magit is extremely powerful for experienced Emacs users who prefer command driven workflows. SmartGit aims to make advanced Git workflows accessible, transparent, and safe for a much broader range of developers.
- masklinn 8mo ago
  I personally don’t care for rebasing in magit (I actually find it confusing when hitting conflicts). My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits.
  - mschulze 8mo ago
    Right - actually, for conflicts I switch to IntelliJ.
- taude 8mo ago
  I used to use Magit, but once I discovered LazyGit four years ago, I never looked back. No Emacs bloat and a great TUI-based UX with quick single key press actions.
  - ziml77 8mo ago
    This is what I need to be sold on magit over. Magit just feels slower (and definitely is slower to start if you're not already in emacs) and less intuitive.
- jwr 8mo ago
  > I never could convince even one to use it Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times.
- zelphirkalt 8mo ago
  Same experience here. Showed it to coworkers, but none was interested in making their tooling work well. Even looking for a VSCode equivalent for them (edamagit) no one was even willing to try. Yet people complained about many branches in repos, which didn't impact me at all, but for their GUI git clients apparently were a problem, and so we switched to deleting branches upon merge, discarding some git history along with that (when something was merged).
- sureglymop 8mo ago
  It looks really cool but the thing is, having learned git just as a cli tool, I don't think any UI would convert me from that workflow. The exception is maybe diffing, where I just use meld as the difftool.
  - rgoulter 8mo ago
    I think you're missing out on magit. With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy. For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit. Or magit makes it easy to stage/unstage line by line.
- Perz1val 8mo ago
  I'll never touch any git wrapper, because they've lied to me before and I can use git already. Everything that was there to be sped up has already been made into zsh functions.
- e40 8mo ago
  My exact experience, though I did learn it from a co-worker, so at least he did succeed. :)
skydhash 8mo ago
Magit does give you a surgeon control over the scapel that git is. Most git GUI wants to give you a nice dashboard. The latter is OK if you just want some logs stored (aka git commit and git push), but version control can be a powerful tool especially considering how non linear programming can be. A patch is an idea, not some snapshot of time. git allows for ideas manipulation. The rebase operation is adjusting ideas to fit a context. And with the reflog (which tracks every operations), you have undo for ideas manipulation.
tambourine_man 8mo ago
Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.
- kqr 8mo ago
  You can use Magit even if you're a Vim user. You don't have to buy into the whole Emacs system – you can treat Emacs as the virtual machine that runs Magit.
  - mschulze 8mo ago
    Yes, I use Emacs 90% just for magit (and 10% for org-mode for some time tracking), but no text editing or coding at all.
  - tambourine_man 8mo ago
    Yeah, but it's not as convenient.
- scocide 8mo ago
  Magit was the only thing keeping me in emacs for a long time, but the neovim clone, neogit, is now 90% of the way there for my use cases, same interface same everything
  - tambourine_man 8mo ago
    I need to move to Neovim. Thanks for the nudge.
    - brcmthrowaway 8mo ago
      Any tips on how?
      - tambourine_man 8mo ago
        Depends on where you’re coming from. If you have a decades old .vimrc like I do, that meant a few conditionals to load niceties such as LSP when running on nvim. I got that mostly working but there are still a few things missing. If you’re starting from scratch, that’s much easier.
nopurpose 8mo ago
I was missing magit, but then found `gitu` CLI and now use it happily for rebasing.
sandinmyjoints 8mo ago
Rebasing in magit is so choice. I especially love magit-rebase-subset.
jonpalmisc 8mo ago
Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim -es --cmd 'vim.cmd("q")' 0.02s user 0.01s system 82% cpu 0.034 total Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading. Emacs is my favorite editor, full stop. But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.
- ahoka 8mo ago
  /usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys Altough I'm not using Emacs.app.
  - jonpalmisc 8mo ago
    Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.
- ishouldbework 8mo ago
  While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.
  - jonpalmisc 8mo ago
    Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
gnuduncan 8mo ago
magit is still my best firend in emacs :)
deleted 8mo ago
[deleted]
codingcareer 8mo ago
A couple years back I was tinkering with a spacemacs setup and I loved Magit! Over the years I opted to substitute most tools with simpler, UI-based ones (like LogSeq for org-mode) but I never found a good substitution for Magit. Having a whole spacemacs setup just for one tool is a bit overkill though, so I just use basic git and accept having to deal with interactive rebases manually.
- vvillena 8mo ago
  I have a Emacs + Spacemacs setup only for Magit. The base Spacemacs config works well, so I never had the need to tinker with it. Nowadays I don't care much about the rest of Emacs. It stays out of the way, and I keep happily using Magit.
antonyh 8mo ago
I bounced for a while between Magit and Tig, then ended up just using whatever the IDE provided combined with the CLI. I'm a frequent-but-not-daily Emacs user, so it boils down to the friction of switching tools. I should give up the Jetbrains IDEs and go all in on Emacs.
skrebbel 8mo ago
Ilove everything about this post. "It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"
- PaulDavisThe1st 8mo ago
  from TFA: > That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.
  - skrebbel 8mo ago
    Fair, my comment was stupid and should've been downvoted
- txru 8mo ago
  These are indicated through context menus throughout specifying what the responses should be. It's a minimal UI though, and where `git rebase` is confusing magit rebase is confusing.
- onfir3 8mo ago
  Exactly my thought
- akagr 8mo ago
  The important part is you don’t have to remember that gobbledygook. I don’t know why author posted that key stroke list as it seems to remove value from this post and make it look harder than it is. Magit surfaces all available commands and options for you, along with key shortcuts as well as the actual git cli counterparts if you want to learn the raw command, too.
shpx 8mo ago
I want to quit Magit because it's unbearably slow. In a repo with 6000 files `git status` takes 100ms but the Magit equivalent takes 2-4 seconds.
- ashton314 8mo ago
  This will probably help: ;; Speed up magit status by removing some things (remove-hook 'magit-status-sections-hook 'magit-insert-tags-header) (remove-hook 'magit-status-sections-hook 'magit-insert-status-headers) (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-pushremote) (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-pushremote) (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-upstream) (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-upstream-or-recent)
- BeetleB 8mo ago
  It's because Magit is doing a lot more than just status. It executes multiple git commands to get all the information it wants to display. As a sibling said, you can disable much of that.
- Forge36 8mo ago
  Profiling[1] your own repository and tweaking as necessary (possibly disabling auto-status refresh) will likely yield significant performance improvements. I use magit with a very large repository (100k files, millions of commits) it's still not lightning fast like it is with smaller repositories, I'm still finding it an improvement over the CLI. My config notes this saves me ~13 seconds in git-status (remove-hook 'magit-status-headers-hook 'magit-insert-tags-header) [1]: https://docs.magit.vc/devel/magit/Performance.html https://docs.magit.vc/devel/magit/Performance.html
chriswarbo 8mo ago
I've been using magit for years, and it's the reason I avoided giving the jujutsu VCS a try: the `jj` workflow/UI is supposedly much nicer than the `git` workflow/UI; but since I use magit more than bare `git` commands, that wasn't enough to sell me. I finally gave it a try when I came across the majutsu package, which is a magit-like interface for jujutsu. I recommend it for Emacs/magit users wanting to try `jj`!
- tcoff91 8mo ago
  I really love the jjui TUI. For non-emacs users who want a great TUI for jj definitely check it out.
  - baq 8mo ago
    one thing I'm missing in jjui which jj cmdline does natively is rebase onto multiple heads - using this for quickly testing my branch on some other pr and latest main. other than that agreed, helps a lot with tedious noting down of change id prefixes.
    - Zambyte 8mo ago
      This is something I've never done before. Are you just repeating -o, creating a merge commit? If that's the case, it also seems like you can do jj duplicate and repeat -o if you just want to create a branch to temporarily test against another branch and main.
      - baq 8mo ago
        yes, exactly this, multiple -o. I sometimes have two or three branches which I keep a single merge branch on top of and being able to switch out the parents is super convenient.
    - i_dursun 8mo ago
      you can do this by using the "set parents" operation (shift+m) which allows you to add/remove parents to a revision. https://idursun.github.io/jjui/revisions/set-parents/ https://idursun.github.io/jjui/revisions/set-parents/
jwr 8mo ago
Magit is absolutely wonderful. It is one of the main tools I use daily to get my work done, especially now that AI does a lot of the work for me. I spend a lot of my time in magit looking at diffs! I would encourage anyone who relies on magit to sponsor tarsius to make his fantastic work sustainable.
jwr 8mo ago
One of my favorite magit tricks: cF (commit with instant fixup). This lets you add a single-line change to a commit way back somewhere in the log.
- aardvark179 8mo ago
  cF is the command you want for this.
SoftTalker 8mo ago
Magit is absolutely the only reason I'm able to use git. And even at that it's still confusing. Yes I know tens of thousands of devs use it every day. I've got some kind of mental block with git. I used to use Mercurial and Subversion without any issues.
tom_ 8mo ago
Possibly related: this post about Lotus 1-2-3: https://news.ycombinator.com/item?id=47279633 https://news.ycombinator.com/item?id=47279633 The Emacs interface in general isn't massively like Lotus 1-2-3's, but magit's somewhat is. The above post goes into a bunch of detail, but what I remember most about my time using 1-2-3 (a long time ago now) was that the shortcuts were super easy to get accustomed to, because there was a prompt of some kind every step of the way. magit's rather similar prompts work well in this respect too. (Though you do still have to know how to use git. This is git, after all.) Where there might be some more general overlap with Emacs: an apparent goal of Lotus 1-2-3 was, like Emacs, that its users would be able to automate it, and without too much bother given their knowledge of how to operate it in general. It's actually better than Emacs in this respect, because the macros seemed to be largely based on the keys you press; Emacs, by contrast, makes you jump through some hoops to figure out what the corresponding elisp for some sequence of keys might be. (The hoops are not hard to jump through! But they are there.) (Along similar lines: Autodesk's Maya. And, to an extent, 3D Studio Max - though the scriptability there felt merely comprehensive, rather than pervasive. MaxScript was measurably less horrid than MEL though.)
haskman 8mo ago
Vim/Neovim users should look at LazyGIT. https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE The best part - it's a TUI program that's usable independently, that also happens to embed really well within vim.

224 points by ibobev 8mo ago

I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using --onto, see https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_interesting_rebases https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_...) are a breeze with Magit. I can't remember the order of branches to use on the CLI, in Magit it's just "r s" basically. It's really magic.

lambda 8mo ago
Magit is absolutely the best Git GUI ever. Unfortunately, for most people the fact that it's part of Emacs is a blocker. And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit. So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.
- troupo 8mo ago
  The best gut GUI is GitUp: https://gitup.co/ https://gitup.co/ Magit is not even close to be on the same level. Any insane operation you want at your fingertips.
  - deleted 8mo ago
    [deleted]
  - jbstack 8mo ago
    It's Mac-only. That's a pretty serious limitation for a modern Git tool.
  - MainlyMortal 8mo ago
    I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.
    - znpy 8mo ago
      > I don't even use a Mac any more after 20 years So the software is mac-only, you haven't used a mac in over 20 years so you haven't used this software and yet... you claim it's better than magit? i mean, it's very dishonest at best.
      - troupo 8mo ago
        The claim was that its GUI is better than Magit's, following this claim: "Magit is absolutely the best Git GUI ever."
        lambda 8mo ago
        It may be prettier looking. I've seen many Git GUIs that are prettier than Magit. But none of them that I've tried have ever come close to the workflow. I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs. Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI". So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
        troupo 8mo ago
        > I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs. I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts. My most common workflow besides staging anything is (to make sure history is clean): - split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit) - move new commit up/down the branch (doesn't require interactive rebase in GitUp) - squash up/down (undo/redo from time to time) As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent > Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI". The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2] However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason. [1] I only have this blog post to confirm https://www.howardism.org/Technical/Emacs/magit-squashing.html https://www.howardism.org/Technical/Emacs/magit-squashing.ht... [2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.
  - ileonichwiesz 8mo ago
    Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?
    - troupo 8mo ago
      > Isn’t this just something that any IDE has built-in these days? In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too). Some of my idiosyncratic usage I developed with GitUp doesn't even exist in most (all?) Git tools: https://news.ycombinator.com/item?id=47329489 https://news.ycombinator.com/item?id=47329489 (see my most common workflow)
- w4rh4wk5 8mo ago
  I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover.
  - zelphirkalt 8mo ago
    I am not someone to recommend VSCode, but if you are already using it, you could check out edamagit. I think in the Vim world there is also some equivalent.
  - MobileVet 8mo ago
    Run spacemacs in ‘evil mode’ so you can use Vim!
- saila 8mo ago
  Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care). The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
  - hrmtst93837 8mo ago
    [flagged]
- imiric 8mo ago
  Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit. Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command. This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
- znpy 8mo ago
  > Unfortunately, for most people the fact that it's part of Emacs is a blocker. OT but i've learned the hard way not to push people into emacs. a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs . Reality is, i didn't want to have that role and that colleague wasn't interested in gnu emacs in the first place. That was a very stupid mistake on my side. Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances". Some people are intrigued, most other absolutely aren't... And it's fine.
  - kqr 8mo ago
    Surely the mistake here is conflating "learning Magit" with "learning Emacs"? I can run Java applications while knowing nearly nothing about the JVM. The same is true for applications based on Emacs.
    - steve1977 8mo ago
      One does not simply use Emacs.
      - worik 8mo ago
        I simply used Emacs for 25 years, avoiding editing .emacs entirely Only in the past years have I started customizing it My attraction to Emacs is stability and I can use it in text or GUI mode. Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs
    - tsimionescu 8mo ago
      Magit is not an "application based on Emacs", it's an extremely powerful git plugin for someone who is already using Emacs. If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase. Even the fact that you'd have to learn Emacs' extremely idiosyncratic keyboard shortcuts, and even keyboard shortcut help (what do you mean "save is C-x C-s?" what does that even mean?) is a huge problem not worth the effort. And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.
- publicdebates 8mo ago
  https://github.com/magit/magit/issues/3961 https://github.com/magit/magit/issues/3961
- moritzwarhier 8mo ago
  Personally, I'm not a Git magician, but I prefer the Git CLI for most operations. Only exception is resolving conflicts. The most important point for every gut IDE integration to me is that it cleanly maps to the file system and CLI state.
  - mr_mitm 8mo ago
    Staging single lines or hunks is also much easier in a TUI/GUI. I wouldn't even know how to do it with just git.
    - stackbutterflow 8mo ago
      git add -p
      - deleted 8mo ago
        [deleted]
      - kirici 8mo ago
        Operates on hunks, which may at times be multiple lines that cannot be split further
        throw-the-towel 8mo ago
        You can edit a hunk with `e`. Clunky but it works.
        nothrabannosir 8mo ago
        In a conversation about magit, this is comparing jumping off a sidewalk to powered flight.
        yacin 8mo ago
        oftentimes splitting the hunks with `s` is enough.
- badsectoracula 8mo ago
  > Magit is absolutely the best Git GUI ever. But it isn't graphical :-P. Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux. Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist). I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it. In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself). https://fuel-scm.org/fossil/index https://fuel-scm.org/fossil/index
- 0x1ceb00da 8mo ago
  > Magit is absolutely the best Git GUI ever Not even close. Claude and codex are the best git gui.
erksa 8mo ago
Same, emacs being the barrier for most.
jayd16 8mo ago
What makes something easier in magit than, for example, SmartGit?
- mschulze 8mo ago
  I haven't used SmartGit, so I can't really compare. I would single out the following for Magit: 1. Single key strokes for actions and toggles 2. Discoverability through "slide-ins" (TFA also explains this) For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do. So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2. If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts.
  - zelphirkalt 8mo ago
    I would also highlight that in Emacs magit one can always drop back to command line by pressing "!", which I do, when I don't know how to do something in Magit. Like "git submodule update --init --recursive".
- plieber 8mo ago
  Magit feels very efficient to many developers because it is essentially a thin layer over Git itself. If you already know Git commands and work comfortably inside Emacs, Magit lets you trigger many operations extremely quickly using short key sequences. In that sense it is very close to the mental model of Git. However, that efficiency comes with a prerequisite: you need to remember commands, understand Git concepts well, and work inside a keyboard driven environment. SmartGit focuses on a different kind of efficiency. Instead of optimizing for memorizing commands, it optimizes for visual understanding and discoverability. Complex operations like rebasing, resolving conflicts, working with multiple repositories, or managing submodules become easier because the state of the repository is immediately visible and actions are guided. So the difference is less about what Git can do and more about how quickly a developer can understand and control what is happening. Magit is extremely powerful for experienced Emacs users who prefer command driven workflows. SmartGit aims to make advanced Git workflows accessible, transparent, and safe for a much broader range of developers.
masklinn 8mo ago
I personally don’t care for rebasing in magit (I actually find it confusing when hitting conflicts). My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits.
- mschulze 8mo ago
  Right - actually, for conflicts I switch to IntelliJ.
taude 8mo ago
I used to use Magit, but once I discovered LazyGit four years ago, I never looked back. No Emacs bloat and a great TUI-based UX with quick single key press actions.
- ziml77 8mo ago
  This is what I need to be sold on magit over. Magit just feels slower (and definitely is slower to start if you're not already in emacs) and less intuitive.
jwr 8mo ago
> I never could convince even one to use it Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times.
zelphirkalt 8mo ago
Same experience here. Showed it to coworkers, but none was interested in making their tooling work well. Even looking for a VSCode equivalent for them (edamagit) no one was even willing to try. Yet people complained about many branches in repos, which didn't impact me at all, but for their GUI git clients apparently were a problem, and so we switched to deleting branches upon merge, discarding some git history along with that (when something was merged).
sureglymop 8mo ago
It looks really cool but the thing is, having learned git just as a cli tool, I don't think any UI would convert me from that workflow. The exception is maybe diffing, where I just use meld as the difftool.
- rgoulter 8mo ago
  I think you're missing out on magit. With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy. For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit. Or magit makes it easy to stage/unstage line by line.
Perz1val 8mo ago
I'll never touch any git wrapper, because they've lied to me before and I can use git already. Everything that was there to be sped up has already been made into zsh functions.
e40 8mo ago
My exact experience, though I did learn it from a co-worker, so at least he did succeed. :)

skydhash 8mo ago

Magit does give you a surgeon control over the scapel that git is. Most git GUI wants to give you a nice dashboard. The latter is OK if you just want some logs stored (aka git commit and git push), but version control can be a powerful tool especially considering how non linear programming can be. A patch is an idea, not some snapshot of time. git allows for ideas manipulation. The rebase operation is adjusting ideas to fit a context. And with the reflog (which tracks every operations), you have undo for ideas manipulation.

tambourine_man 8mo ago

Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.

kqr 8mo ago
You can use Magit even if you're a Vim user. You don't have to buy into the whole Emacs system – you can treat Emacs as the virtual machine that runs Magit.
- mschulze 8mo ago
  Yes, I use Emacs 90% just for magit (and 10% for org-mode for some time tracking), but no text editing or coding at all.
- tambourine_man 8mo ago
  Yeah, but it's not as convenient.
scocide 8mo ago
Magit was the only thing keeping me in emacs for a long time, but the neovim clone, neogit, is now 90% of the way there for my use cases, same interface same everything
- tambourine_man 8mo ago
  I need to move to Neovim. Thanks for the nudge.
  - brcmthrowaway 8mo ago
    Any tips on how?
    - tambourine_man 8mo ago
      Depends on where you’re coming from. If you have a decades old .vimrc like I do, that meant a few conditionals to load niceties such as LSP when running on nvim. I got that mostly working but there are still a few things missing. If you’re starting from scratch, that’s much easier.

nopurpose 8mo ago

I was missing magit, but then found `gitu` CLI and now use it happily for rebasing.

sandinmyjoints 8mo ago

Rebasing in magit is so choice. I especially love magit-rebase-subset.

jonpalmisc 8mo ago

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim -es --cmd 'vim.cmd("q")' 0.02s user 0.01s system 82% cpu 0.034 total Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading. Emacs is my favorite editor, full stop. But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.

ahoka 8mo ago
/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys Altough I'm not using Emacs.app.
- jonpalmisc 8mo ago
  Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.
ishouldbework 8mo ago
While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.
- jonpalmisc 8mo ago
  Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

gnuduncan 8mo ago

magit is still my best firend in emacs :)

deleted 8mo ago

[deleted]

codingcareer 8mo ago

A couple years back I was tinkering with a spacemacs setup and I loved Magit! Over the years I opted to substitute most tools with simpler, UI-based ones (like LogSeq for org-mode) but I never found a good substitution for Magit. Having a whole spacemacs setup just for one tool is a bit overkill though, so I just use basic git and accept having to deal with interactive rebases manually.

vvillena 8mo ago
I have a Emacs + Spacemacs setup only for Magit. The base Spacemacs config works well, so I never had the need to tinker with it. Nowadays I don't care much about the rest of Emacs. It stays out of the way, and I keep happily using Magit.

antonyh 8mo ago

I bounced for a while between Magit and Tig, then ended up just using whatever the IDE provided combined with the CLI. I'm a frequent-but-not-daily Emacs user, so it boils down to the friction of switching tools. I should give up the Jetbrains IDEs and go all in on Emacs.

skrebbel 8mo ago

Ilove everything about this post. "It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"

PaulDavisThe1st 8mo ago
from TFA: > That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.
- skrebbel 8mo ago
  Fair, my comment was stupid and should've been downvoted
txru 8mo ago
These are indicated through context menus throughout specifying what the responses should be. It's a minimal UI though, and where `git rebase` is confusing magit rebase is confusing.
onfir3 8mo ago
Exactly my thought
akagr 8mo ago
The important part is you don’t have to remember that gobbledygook. I don’t know why author posted that key stroke list as it seems to remove value from this post and make it look harder than it is. Magit surfaces all available commands and options for you, along with key shortcuts as well as the actual git cli counterparts if you want to learn the raw command, too.

shpx 8mo ago

I want to quit Magit because it's unbearably slow. In a repo with 6000 files `git status` takes 100ms but the Magit equivalent takes 2-4 seconds.

ashton314 8mo ago
This will probably help: ;; Speed up magit status by removing some things (remove-hook 'magit-status-sections-hook 'magit-insert-tags-header) (remove-hook 'magit-status-sections-hook 'magit-insert-status-headers) (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-pushremote) (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-pushremote) (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-upstream) (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-upstream-or-recent)
BeetleB 8mo ago
It's because Magit is doing a lot more than just status. It executes multiple git commands to get all the information it wants to display. As a sibling said, you can disable much of that.
Forge36 8mo ago
Profiling[1] your own repository and tweaking as necessary (possibly disabling auto-status refresh) will likely yield significant performance improvements. I use magit with a very large repository (100k files, millions of commits) it's still not lightning fast like it is with smaller repositories, I'm still finding it an improvement over the CLI. My config notes this saves me ~13 seconds in git-status (remove-hook 'magit-status-headers-hook 'magit-insert-tags-header) [1]: https://docs.magit.vc/devel/magit/Performance.html https://docs.magit.vc/devel/magit/Performance.html

chriswarbo 8mo ago

I've been using magit for years, and it's the reason I avoided giving the jujutsu VCS a try: the `jj` workflow/UI is supposedly much nicer than the `git` workflow/UI; but since I use magit more than bare `git` commands, that wasn't enough to sell me. I finally gave it a try when I came across the majutsu package, which is a magit-like interface for jujutsu. I recommend it for Emacs/magit users wanting to try `jj`!

tcoff91 8mo ago
I really love the jjui TUI. For non-emacs users who want a great TUI for jj definitely check it out.
- baq 8mo ago
  one thing I'm missing in jjui which jj cmdline does natively is rebase onto multiple heads - using this for quickly testing my branch on some other pr and latest main. other than that agreed, helps a lot with tedious noting down of change id prefixes.
  - Zambyte 8mo ago
    This is something I've never done before. Are you just repeating -o, creating a merge commit? If that's the case, it also seems like you can do jj duplicate and repeat -o if you just want to create a branch to temporarily test against another branch and main.
    - baq 8mo ago
      yes, exactly this, multiple -o. I sometimes have two or three branches which I keep a single merge branch on top of and being able to switch out the parents is super convenient.
  - i_dursun 8mo ago
    you can do this by using the "set parents" operation (shift+m) which allows you to add/remove parents to a revision. https://idursun.github.io/jjui/revisions/set-parents/ https://idursun.github.io/jjui/revisions/set-parents/

jwr 8mo ago

Magit is absolutely wonderful. It is one of the main tools I use daily to get my work done, especially now that AI does a lot of the work for me. I spend a lot of my time in magit looking at diffs! I would encourage anyone who relies on magit to sponsor tarsius to make his fantastic work sustainable.

jwr 8mo ago

One of my favorite magit tricks: cF (commit with instant fixup). This lets you add a single-line change to a commit way back somewhere in the log.

aardvark179 8mo ago
cF is the command you want for this.

SoftTalker 8mo ago

Magit is absolutely the only reason I'm able to use git. And even at that it's still confusing. Yes I know tens of thousands of devs use it every day. I've got some kind of mental block with git. I used to use Mercurial and Subversion without any issues.

tom_ 8mo ago

Possibly related: this post about Lotus 1-2-3: https://news.ycombinator.com/item?id=47279633 https://news.ycombinator.com/item?id=47279633 The Emacs interface in general isn't massively like Lotus 1-2-3's, but magit's somewhat is. The above post goes into a bunch of detail, but what I remember most about my time using 1-2-3 (a long time ago now) was that the shortcuts were super easy to get accustomed to, because there was a prompt of some kind every step of the way. magit's rather similar prompts work well in this respect too. (Though you do still have to know how to use git. This is git, after all.) Where there might be some more general overlap with Emacs: an apparent goal of Lotus 1-2-3 was, like Emacs, that its users would be able to automate it, and without too much bother given their knowledge of how to operate it in general. It's actually better than Emacs in this respect, because the macros seemed to be largely based on the keys you press; Emacs, by contrast, makes you jump through some hoops to figure out what the corresponding elisp for some sequence of keys might be. (The hoops are not hard to jump through! But they are there.) (Along similar lines: Autodesk's Maya. And, to an extent, 3D Studio Max - though the scriptability there felt merely comprehensive, rather than pervasive. MaxScript was measurably less horrid than MEL though.)

haskman 8mo ago

Vim/Neovim users should look at LazyGIT. https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE The best part - it's a TUI program that's usable independently, that also happens to embed really well within vim.