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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
If you haven’t seen it you may want the fugitive plugin for vim. It seems to give a reasonable level of git magic within vim. Maybe not as magic as magit, but it does a lot including good handling of interactive rebases.
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.
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.
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.
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:
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.
I 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...
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.
Altough I'm not using Emacs.app.
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.
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.
Magit is not even close to be on the same level.
Any insane operation you want at your fingertips.
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.
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.
"It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"
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.
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.