Discussion
Entropic Thoughts
skydhash: 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.
mschulze: 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_...) 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.
tambourine_man: Magit is one of the few things that makes me, as a Vim user, envy Emacs. An org-mode, since I'm being honest.
kqr: 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.
tambourine_man: Yeah, but it's not as convenient.
scocide: 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
lambda: 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.
tambourine_man: I need to move to Neovim. Thanks for the nudge.
antonyh: 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.
codingcareer: 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.
masklinn: I personally don’t care for rebasing in emacs (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.
jonpalmisc: 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.
ishouldbework: 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: 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, `projectile-find-file` being slow in large repos, etc. all remain.
jayd16: What makes something easier in magit than, for example, SmartGit?
mschulze: 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.
skrebbel: Ilove everything about this post."It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"
shpx: [delayed]
chriswarbo: 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`!
ashton314: [delayed]
dietr1ch: > Emacs is still so much slower than Neovim, even in the case of launching and immediately quittingI agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]).I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down.[^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_star...
dietr1ch: > having a globally shared buffer state, etc. is an anti-featureYeah, it feels a bit weird to not have some isolation.Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default).[^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...
8s2ngy: I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.
PaulDavisThe1st: 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.
chriswarbo: > I think having a globally shared buffer state, etc. is an antifeature.As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of.It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)
ragall: > Plus, there's no reason that starting a TUI program should be that slow.There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.
precompute: Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous.I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest!There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.
precompute: >a lot of cruftLike what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
umanwizard: The vast majority of emacs is written in lisp, not C.
precompute: Emacs has globally shared buffer state amongst the frames that share the same "base frame" (no idea what this is called) or the same socket (could be wrong here).Anyway, you can start N emacs instances and they can all have individual buffer states.Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.Text insertion lag is something I haven't experienced since 2019. Config issue?project-find-file might be slow because of low gc-cons-threshold. I know consult gets around this by temporarily raising the threshold. These days, you can use the feature/igc branch to make these operations faster (although they are pretty fast anyway).If you think emacs lacks <fundamental feature X>, think again!
w4rh4wk5: 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: 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.
tcoff91: jj with jjui is even better, coming from someone who used magit for years.
onfir3: Exactly my thought
zelphirkalt: Emacs' hard to solve issue is its use of global mutable state all across the board, which makes concurrency and parallelism very hard to add properly. It will take a lot of effort to slowly carefully reduce the error/bug surface and add proper parallelism constructs, that are easy to use for any package author.
imiric: 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.
publicdebates: https://github.com/magit/magit/issues/3961
