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.

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.

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.

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.

> 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.

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).

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.

What makes something easier in magit than, for example, SmartGit?

Same, emacs being the barrier for most.

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.

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.

On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization.

    $ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))'
    30.2
    0.07user 0.03system 0:00.13elapsed 78%CPU (0avgtext+0avgdata 46064maxresident)k

    $ /usr/bin/time ~/bin/emacs --batch -eval '(princ (format "%s\n" emacs-version))'
    30.2
    0.02user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 57728maxresident)k

> Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting

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...

Emacs is functionally a shell not an editor. Starting Emacs for each file is akin to starting and stopping Wayland for every web page you open.

So the miniscule increase in start time is a non issue

Emacs can certainly be sluggish, but I'm not sure how much that's e.g. inherent to ELisp, or due to synchronous/single-threaded code, or choosing slow algorithms for certain tasks, etc.

For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect.

Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!

my non-command line gui version of doom emacs with a bunch of packages enabled loads up fully for me in 0.45s which is hardly slow. sure it's slower than neovim but also not slow in the absolute sense and i don't have the emacs daemon running which would make that even faster.

What hardware are you on?

On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX?

  $ time emacs -Q -e kill-emacs
  real    0m0.076s
  user    0m0.058s
  sys     0m0.018s

  $ time nvim -es --cmd 'vim.cmd("q")'
  real    0m0.028s
  user    0m0.005s
  sys     0m0.003s

vim still is a lot faster though.

    $ time nvim -es --cmd 'vim.cmd("q")'

    real 0m0.057s
    user 0m0.016s
    sys 0m0.017s

    $ time emacs -Q -e kill-emacs

    real 0m0.230s
    user 0m0.165s
    sys 0m0.064s

    $ time emacs -nw -Q -e kill-emacs

    real 0m0.095s
    user 0m0.057s
     sys 0m0.017s

  $ time emacs -nw -Q -e kill-emacs
  real    0m0.075s
  user    0m0.062s
  sys     0m0.013s

/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys

Altough I'm not using Emacs.app.

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.

I'm not sure I'm capable of noticing or caring about the difference between 0.18 and 0.02 seconds for something that doesn't happen on a rapid cadence.

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.

Is there anything prominently missing in majutsu?

I really love the jjui TUI. For non-emacs users who want a great TUI for jj definitely check it out.

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.

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

jj with jjui is even better, coming from someone who used magit for years.

jj/jjui should have you covered

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)

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.

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.

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.

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.

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.

Exactly my thought