
Magit – A Git Porcelain inside Emacs - tosh
https://magit.vc
======
cityzen
Was going to make a joke about toilets but after some research realized
porcelain does refer to a toilet in this case. Learn something new every day.

In case anyone is curious:

But because Git was initially a toolkit for a version control system rather
than a full user-friendly VCS, it has a number of subcommands that do low-
level work and were designed to be chained together UNIX-style or called from
scripts. These commands are generally referred to as Git’s “plumbing”
commands, while the more user-friendly commands are called “porcelain”
commands.

[https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...](https://git-
scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)

------
michaericalribo
Magit is magic: coupled with customization via elisp, it feels smooth as
butter to navigate hairy rebases, commit individual lines in changed files, or
jump to open a PR in a browser.

One of my daily drivers for development, and a real killer extension to emacs

~~~
globuous
I also love:

\- magit-blame: show the commits for each line \- magit-find-file: allows you
to open a file from any branch. So you can easily have the same file from two
different branches opened side by side. \- magit-log-buffer-file: shows the
git tree with all commits that modified the file in the current buffer (which
you can then navigate just like you would when doing M-x magit-status l l)

And this package is pretty sweet as well: [https://melpa.org/#/git-
timemachine](https://melpa.org/#/git-timemachine) , it allows you to navigate
the git tree for a given file easily.

~~~
ruricolist
It's not obvious from the name, but magit-log-buffer-file also lets you browse
the history of just the current region.

~~~
yxhuvud
It exist in stock emacs as vc-region-history. Fantastic functionality.

------
robenkleene
For people interested in magit-like features, but don’t use Emacs, I highly
recommend tig ([https://github.com/jonas/tig](https://github.com/jonas/tig)).

Here’s a tweet with a quick video with me using it
([https://twitter.com/robenkleene/status/1299415895262081024](https://twitter.com/robenkleene/status/1299415895262081024)).

It works particularly well with Vim (I prefer it to fugitive, mainly because
it’s more accessible directly from the command line, so it makes a nice
complement to CLI git).

------
dathinab
I really love the discoverability provided by the popups.

Besides that it looks so good that I want to try out emacs.

Currently I'm using vscode, but many (supposedly very good/main/major) plugins
where not so good.

Sometimes fancy looks where favored over usability. Sometimes discoverable of
features was just bad and sometimes they where just buggy (like the typescript
language server).

Edit: just to be clear, Atom was way worse when I did use it before.

~~~
aksell
If you feel like trying out something quite similar to magit via a code plugin
you can have a look at edamagit, it tries to be magit but in vscode. I have
used both magit and edamagit, and edamgit does the job for most features I use
on a day to day basis(the most important one for me is staging/un-
staging/discarding hunks in a easy way), but is is noticeably slower then
magit in emacs. See
[https://github.com/kahole/edamagit](https://github.com/kahole/edamagit)

------
mullikine
Magit has a sub-package called Transient (also made by Jonas Bernoulli) which
is what powers its UI. It's absolutely brilliant for making porcelains.

~~~
pmoriarty
While I absolutely adore Magit, I wonder why it doesn't just use hydra, a well
established package to which Transient is very very similar.[1]

Why don't these two brilliant programmers team up and make one package twice
as good, instead of working on two separate packages and mostly duplicating
effort?

[1] - [https://magit.vc/manual/transient/Comparison-With-Other-
Pack...](https://magit.vc/manual/transient/Comparison-With-Other-
Packages.html)

~~~
tarsius
Internally they are actually quite different. Hydra is much simpler, which has
its benefits. Transient is much more flexible, which it has to pay for with
complexity. There's value in having both options.

------
phonebucket
I see so many emacs things that look cool.

I have vim mainly customised with language servers and the like, which seems
counter to vim's philisophy and closer to emacs.

So I'd love to experiment with emacs properly. But it's so painful; I'm just
so much faster at everything with vim. I understand there are things like evil
and spacemacs to ease the transition, but every time I try them, I just come
straight back to what I'm comfortable with.

Is there anyone else who jumped from vim to emacs. Do you have any tips apart
from perserverance?

~~~
fileeditview
I went from vim to emacs with evil mode (i used the doom distribution, which I
think is great). However I went back after some months of usage. The main
reason is performance. Many plugins are just not very performant with elisp
but without them emacs is pointless for me. Also vim has better support for
more languages in terms of LSP. In emacs I ran into a lot of outdated plugin
issues.

I have customized my vim now with shortcuts very similar to Doom/spacemacs and
many plugins. I am very happy with my setup at the moment. I don't care if it
is against the vim philosophy as long as I get stuff done with it :)

My tip: if you want to try out emacs with evil, try the doom distribution. If
you become a convert you still can configure your own if you want/need to
later on.

~~~
phxonrails
I'm in the same situation. Started with Vim. Tried out Spacemacs and loved it.
Switched to Doom for the performance gains. Finally, switched back to Vim
(Neovim) with Doom-like keybinding; specifically setting leader to Space.

I haven't found anything that comes close to vim's performance as a text
editor. In terms of plugins, there are some great ones for Neovim like tpope's
rails plugins, coc.nvim, fzf, etc.

~~~
narwally
I just switched to Doom from a very trimmed down and customized version of
Spacemacs. I liked Spacemacs layer concepts, but many of them I had installed
for very basic functionality like syntax highlighting and code formatting, but
to get that I had to pull in this huge layer containing multiple packages.
Emacs was constantly getting bogged down by Spacemacs or becoming buggy at my
attempts to speed it up.

Doom is so much better on the performance end, I don't feel the need to keep
an emacs server running all the time just for occasional editing in the
terminal. I'm interested to see how well it performs with emacs-native-comp.
The Doom ui also feels a lot more cohesive. I've never been a vim user, so I
use the default emacs bindings but still have a leader key; Doom's setup with
the leader key is really well thought out and I'm glad that vim concept has
made its way to emacs.

------
duncan_bayne
I have used many Git front-ends over the years, on Windows, MacOS, and Linux.

Magit is the _only_ one that I've found preferable to just using the CLI
tools.

~~~
gumby
Right on. I rarely use the command line for git any more, which was a surprise
to me.

------
trabant00
People who chose it over the default CLI, please give a few examples of why
and how. I forced myself to only use magit for a week and it did not work for
me, CLI is still faster and more flexible. Maybe a week is not enough time,
maybe I'm missing something.

~~~
globular-toast
The first thing that drew me in was how easy it is to build commits. You can
stage individual files, individual hunks and even individual lines really
easily.

Viewing diffs has a great, keyboard-driven UI. If your cursor is on a commit
(for example when you're viewing logs, but it also works in most other places
where you can see commits), you can press space to view the diff, and then use
space and backspace to scroll up and down in the diff. Meanwhile you can still
use n and p to navigate to different diffs. It's very slick.

Rebasing is really fun with magit. I actually look forward to doing a
nontrivial rebase.

------
nickjj
For making commits, does anyone else still stick with using git add -p , along
with the s/e options?

Granted I don't use Emacs but I haven't found any plugin in any editor that
gives the same confidence and flexibility as git add -p.

~~~
nicoburns
Advanced committing (hunk level) is the one thing I use a GUI for. Sublime
merge is pretty ideal for this as it opens instantly, and you can open it from
the command line with the `smerge` command.

~~~
nickjj
> Advanced committing (hunk level) is the one thing I use a GUI for.

Hunk level commits is what git add -p [s/e] lets you do.

You can split hunks with s, and if you need even more fine grain control you
can hit e which opens that specific hunk in your $EDITOR and then you can pick
whatever you want to commit.

~~~
nicoburns
Yeah, I know you _can_ do that. It's just that while I prefer the CLI for most
tasks, I find it's much easier to do hunk selection using a GUI.

------
globular-toast
Magit is by far the best git porcelain, although the only other option is the
CLI, of course.

The difference between a porcelain like magit and some other "front-end" is
you are actually using git. Other front-ends hide git behind new abstractions
(or rather, old abstractions, more like SVN or other centralised VCSs) and I
find that users of these never really understand how git works. I've been
using magit for almost my entire life with git, I don't really know how to use
the CLI, but I consider myself a git expert.

~~~
rpod
Well said. It's the reason I hate Microsoft's Team Explorer built into Visual
Studio. Almost everyone on my team uses it, and as a result, nobody
understands git. The number of merge commits that could have been avoided by a
simple git pull --rebase...

------
Myrmornis
(Plug) If you're interested in adding syntax-highlighting to magit, see
[https://github.com/dandavison/magit-
delta](https://github.com/dandavison/magit-delta).

~~~
mgalgs
This looks awesome... Have you had issues with it breaking across magit
updates?

~~~
Myrmornis
Hi, thanks. No issues like that so far. All it does is add colors using
overlays; so I think that the main/only scope for breakage is if those color
overlays somehow interact badly with magit's use of overlays.

------
fileeditview
I always was fascinated by the power and usability of magit. However for big
repositories it always was way too slow for me. At work I literally waited
minutes for some screens to load.

I dropped it (and Emacs) because of performance issues and now I am happily
using Vim and for Git I use the cli tools as well as lazygit and tig. I am
very happy with these tools.

~~~
rpod
Are you using magit on Windows? I am experiencing the same performance issues
for large repos and am really hoping to find a way to fix this.

~~~
fileeditview
No I used it on Linux. But I once spent a lot of time on this issue and could
not resolve it. At some point I just gave up.

~~~
silly-silly
Thats interesting, I use it for linux kernel work, what part was slow ?

------
steeef
I've been using a Vim clone of Magit for a while with good success:
[https://github.com/jreybert/vimagit](https://github.com/jreybert/vimagit)

Not being an eMacs user, I'm not familiar with the feature differences, but
the workflow of stage/commit is worth it alone.

------
mark_l_watson
I found Magic useful when working on a team for more complex git workflow.

That said, almost all of my git workflow now is simple stuff and I find that
setting up git aliases/abbreviations is best for me, less ceremony.

------
lbj
Magit is great, Im still using Egg for most Git stuff though.

------
vngzs
I truly love Emacs. Magit is part of what I see as its three "killer apps":

\- Magit. Best Git UI ever. The other comments in this thread discuss this, so
it's probably sufficient to remark that it's the only serious Git tool
competitive with Git's own CLI. Equal in power and superior in usability.

\- Org-mode[0]. Nothing comparable for structured text-editing.

\- Slime[1]. When you edit Emacs Lisp, you really want its near-perfect
features around online documentation, jump-to-definition, code completion,
etc. With this foundation you can understand the Emacs internals well enough
to build whatever else you need. It gives you the best, most fully-featured
REPL-ish workflow (C-x C-e to evaluate the current line of Emacs Lisp) within
real source code files I have ever experienced.

However, performance issues have kept me from going all-in on my adoption.
Mostly this takes the form of long load times upon opening a new file type.
Sometimes it's simply a new file, since the whole UI will block on
parsing/analyzing a new source file (depending on the major mode).

Guile Emacs[2] seemed like the only real contender to making this workable.
But it hasn't received enough love over the last 5 years. Guile proper now
supports Emacs Lisp, but the Emacs side of the equation still requires custom
builds, and doesn't support many important features. More importantly, Guile
ELisp is still slower than Emacs at running ELisp. The whole project is a dead
ringer for high-hopes abandonware.

I've moved back to Vim in the meantime, since it reliably opens quickly and
never lags on key input. I use a shell for the rest. But I have tasted the
fruit of what's possible with Emacs. I want it to work for me, and work for
next generation of programmers now gravitating to big piles of Electron like
VSCode or JetBrains IDEs with ridiculous barriers to extensibility[3].

None of the alternatives can replace the kind of tight edit/execute cycle
possible in Emacs, nor the incredible discoverability afforded by a Lisp IDE.

Are there other Emacs performance projects, hacks for speed gains, etc. worth
following?

[0]: [https://orgmode.org/](https://orgmode.org/)

[1]: [https://common-lisp.net/project/slime/](https://common-
lisp.net/project/slime/)

[2]: [https://emacsninja.com/posts/state-of-emacs-lisp-on-
guile.ht...](https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.html)

[3]: [https://www.baeldung.com/intellij-new-custom-
plugin](https://www.baeldung.com/intellij-new-custom-plugin)

~~~
blablablerg
ggcemacs? That is the speedup everyone is talking about these days.

------
chj
Insanely powerful.

------
simias
Slightly off-topic rant: I want this "porcelain" terminology to die, not only
is it redundant (what's wrong with "user interface"?) it's not even coherently
used within git.

So porcelain is supposed to be the opposite of the internal piping of the
application, the user facing part. Fair enough. But then why does "git status"
have a "\--porcelain" option that's meant to generate an output for script
consumption? Shouldn't that be --pipe?

And yes, I do know the history of why it's that way, but the point still
stands, if you need to know arcane implementation details of some command and
backward hacker logic to understand what the hell this "\--porcelain" flag
does, then it's a bad name.

Magit is a Git user interface inside Emacs.

~~~
pmoriarty
I have to agree. I find the term "porcelain" annoying. But this may be due to
me being older than a lot of people for whom the term was already established
by the time they heard it, while for me it's a neologism.

I feel the same about the term "user stories". Why can't they just call them
features?

There's some kind of urge people have to make up new names for old things that
just reeks of sleazy marketing or hipsterism to me.

But, whatever.. I think we both know we're not going to change anybody's mind.

