Magit is a great Emacs tool and by far my favorite way of interacting with git repositories. I use Magit nearly every day.
Unfortunately, refreshing the magit-status
buffer is sluggish when you are working in a large repository.
A few months ago, I became sick of waiting and investigated how to speed up refreshing the status buffer.
After doing some research, I learned about the magit-refresh-verbose
variable.
Setting magit-refresh-verbose
to true causes Magit to print some very useful output to your *Messages*
buffer.
This output shows how many seconds each step of magit-status
takes.
Here is the output for the large repo that caused me to look into this.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
The total time is found in the last line and we can see it took four seconds. Four seconds is an incredibly long time to wait before interacting with Magit.
You can change how much work Magit does by removing functions from the magit-status-sections-hook
with remove-hook
.
I looked at the timings and and tried removing anything I decided was slow and something I didn’t think I’d miss.
For me, that list includes magit-insert-tags-header
, magit-insert-status-headers
, magit-insert-unpushed-to-pushremote
, magit-insert-unpushed-to-upstream-or-recent
, and magit-insert-unpulled-from-upstream
. I also removed magit-insert-unpulled-from-pushremote
.
You remove a function from a hook by adding elisp similar to (remove-hook 'magit-status-sections-hook 'magit-insert-tags-header)
to your Emacs configuration.
I use use-package to configure mine and below is what my magit
section looks like.
Lines 20-25 remove the hooks.
I also hard-code magit-git-executable
to be the full path of the git
executable on line 5 because folks said this made a difference on macOS.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
After this change, my magit-status
buffer refreshes in under half a second.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
What did I lose from the magit-status
buffer as a result of these changes?
Here is screenshot of the original buffer.
And here is the buffer after.
The difference is drastic1. And so is the speed difference.
The increased speed is worth losing the additional information.
I interact with git
very often and much prefer using Magit to do so.
Before these changes, I found myself regressing to using git
at the command line and I don’t find that to be nearly as enjoyable.
Since I’ve made these changes, I’m back to doing 99% of my git
interactions through Magit.
Don’t settle for slow interactions with your computer. Aggressively shorten your feedback cycles and you’ll change how you interact with the machine.
Versions used when writing this article
This post was written with Magit version 20201111.1436
and Emacs 26.3
on macOS 10.15.7
.
I’ve been using these changes for a few months but do not remember or have a record of what Magit version I was using at the time I originally made these changes.
edit on 2020/12/15: I recently upgraded Emacs to tryout the native-comp work and can report this still works with with Emacs 28.0.50
, Magit 20201212.929
, and Git 2.29.2
running in macOS 11.0.1
.
Warning: This reduces the information Magit shows you. The status buffer will be blank if you have no changes. I find this tradeoff to be worth it.
- The before image is even missing some sections that would have gone missing in the after shot since I didn’t want to put the effort.↩