Magit – A Git Porcelain inside Emacs | Hacker News Reader

Magit – A Git Porcelain inside Emacs

magit.vc

177 pointstosh83 comments

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

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

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 , it allows you to navigate the git tree for a given file easily.

magit-blame also allows you to step back through the history for each line by repeatedly pressing b. So after a developer has run formatters for the whole codebase and "broken" git blame, you can still see the real blame by just pressing b twice.

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

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

Thanks for mentioning magit-find-file. I’ve been using magit recently for the ease of doing commits of smaller hunks, but I didn’t know about find-file. I was just in a situation yesterday where I could’ve used it—wound up going to look at the second version of the file in GH.

Could you elaborate on how git-timemachine is different from magit, as the latter also lets one navigate the git tree for a given file, doesn't it?

I knew magit really was magic when all of the sudden I became the guy people went to when they needed help with with their complicated git tasks. Before magit I knew I was only scratching the surface of git's power, but could never figure out the command line interface well enough to do more than the basics. I still don't feel like I'm a git expert, but magit lets me use it like I'm one.

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

Here’s a tweet with a quick video with me using it (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).

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.

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

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.

Yes, Magit's UI is fantastic. I also love Notmuch, which has a similar interface design and a really elegant architecture. Incidentally, Magit's developer is also a Notmuch contributor.

Emacs ecosystem is getting really good. Org, Notmuch and Magit are fantastic for personal management.

I'll have to take a look at that, I love magit's UI for its ease of discovery. Before magit I didn't know that 'git bisect' existed, nor how useful it was.

I can think of a few other utilities that would really benefit from a similar interface. Certain use cases of org-mode come to mind. There's nearly always a way to do what I want in org, but sometimes it's a pain to figure out even simple use cases without going to the docs or a forum. It's just something that seems to go hand in hand with all really powerful tools.

I may play around with writing a custom mode for my particular workflow of using org for literate programming. There are a bunch of commands I find useful, but don't use often enough to have committed to memory. I'd also love to be able to pull up a pop-up buffer, like magit's commit messages, whenever I want to edit a source block in more detail.

Hydra can be used to create UI in emacs for hints/speed https://github.com/abo-abo/hydra

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

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.

Transient is one of my favorite packages now.

I replaced all my custom keybindings into transient under just one C-j keybinding. Now I have a meaningful popup window with my custom keybindings, so I don't have to remember the less-frequently used bindings.

Also, transient has this one cool feature, where you can configure a timeout to delay the popup window, which is also nice.

docker.el also uses transient. I rate transient over hydra for the specific purpose of making porcelains. I think it's very well suited to the task. docker.el is magit for docker. It's just as life changing. I think docker needed this even more than git.

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?

I've always been an emacs user, so no help from me I'm afraid. But I've read from other vimmers that doom emacs is a very good transition when migrating from vim to emacs, better than spacemacs. I've tried both, and I feel like doom is easier to use overall, so take that as you will.

It's not bad to stick with vim either anyway, it's a great tool itself.

I use vim every now and then, and I have the exact same experience of "well, if only I could just do X like in emacs, this would go way faster". In the end they're different cultures.

You just have to recognize that Lisp is the only true path, and let that guide you to salvation.

That’s not even a joke. The ability to write elisp and bind it to keys is much more useful than the “text editing as programming language” paradigm of vi. Vi is the better text editor, hands down. But enacts is the better text and software environment.

I made the jump from vim to emacs without relying on evil or spacemacs, working my way through the built-in tutorial (C-h t) and doing my own customization from the bottom up. Surprisingly, you don't need that much customization to get productive in emacs, so it's better to find out for yourself what you need.

The mnemonics of the emacs keybindings are part of what makes it so special, so it didn't make much sense to me to use evil-mode. Spacemacs is another layer of abstraction which makes it easier to get started, but ultimately hinders your customizability and understanding of the text editor you are using.

I know you specifically asked for tips that apart from perseverance, but I believe this is the reason I stuck with it for the past 2 years. But beware: mastering emacs is a lifelong hobby, where you sometimes sacrifice short-term productivity for long-term happiness.

> but ultimately hinders your customizability and understanding of the text editor you are using.

[Citation Needed] Spacemacs is just elisp. It is documented and you can explore its source the same as anything else in emacs. `SPC h d` + `which-key` is a godsend for learning and understanding what emacs offers.

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.

Interesting. I am a bit behind you and have recently transitioned to (Doom) Emacs. What plugins were slow for you? What things did you find indispensable and reimplement in vim?

To be clear, my issues were mostly not with doom but with emacs plugins themselves.

Well Magit was clearly the slowest. Used in big repos with a big list of changes it grinded for minutes before showing the "status" screen e.g.

Also various code completion plugins via LSPs were significantly slower than even VSCode and of course vim. While typing I often encountered lag even on fast systems. Not sure if the lag actually came from the LSP plugin or from something like Flycheck ui.

TBH the one thing I "reimplemented" was the keyboard shortcut system which extensively relies on leader(s). In the beginning I just mirrored doom shortcuts but after a while I customized, more suitable to my own needs.

Not really related to emacs but the vim plugins I would not like to miss are especially: coc.nvim, fzf.vim, ranger, vim-fugitive, vim-mergetool, vim-bookmarks

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.

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.

I would suggest a step further: start with Spacemacs/Doom, but if you decide to stick around, try to build your own Emacs configuration based on the part of Spacemacs/Doom that you like.

Thanks to the amazing use-package[1] macro (which Spacemacs/Doom also uses) most configurations are self-contained to a certain extent. Searching for use-package in GitHub[2] will yields plenty of results which can be mostly be taken as a reference for your own liking. It should be relatively easy to port part of Spacemacs/Doom to vanilla use-package, e.g. starting with this (which sets up use-package alongside with evil):

    (require 'package)
    (setq package-enable-at-startup nil)
    (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))

    (package-initialize)
    (unless (package-installed-p 'use-package)
      (package-refresh-contents)
      (package-install 'use-package))

    (eval-when-compile
      (require 'use-package))

    (use-package evil
      :ensure t
      :config
      (evil-mode t) 

    (use-package evil-leader
      :after evil
      :ensure t
      :config
      (evil-leader/set-leader "<SPC>")
      (global-evil-leader-mode t))

To add Magit, one could take a look at Spacemacs's git/packages.el[2], search documentation on what each package does, and proceed on porting configuration, only the part that you actually uses, e.g.:

    (use-package evil-magit
      :ensure t
      :after (magit evil))

    (use-package magit
      :ensure t
      :config
      (evil-leader/set-key ("gs" #'magit-status))

Since most configurations based on use-package are self-contained, when stuck I also like to use GitHub search to look on how other people configure a certain package[3]. In most cases the configuration should be reusable as-is.

Finally, use-package is highly extensible. There is straight.el[4] which adds extension to use-package to fetch from Git and pin a version in a lockfile, which adds reproducibility to Emacs configuration. There's also el-patch[5] from the same author that allows patching package on the fly without the need to maintain separate forks.

[1]: https://github.com/jwiegley/use-package

[2]: https://github.com/syl20bnr/spacemacs/blob/d46eacd83842815b2...

[3]: https://github.com/search?l=Emacs+Lisp&p=4&q=use-package&typ...

[4]: https://github.com/raxod502/straight.el

[5]: https://github.com/raxod502/el-patch

I'd recommend Doom for anyone that wants to base their own configurations on one of these. It's not as big of an abstraction layer on top of vanilla emacs, so it's easier to pull apart and reuse.

I've used vim for about 5 years and switched directly to "vanilla" emacs (no evil or doom).

My main motivator was similar to yours. Most functionality I used came from plugins, but the language used to write plugins or other modifications felt crippled. When I came across orgmode, during my years on the university, I tried it in vim, through some Plugin. I liked how the format allowed me to dump most of my brain in plain text, but it still felt unnatural to edit it with vim.

During a history course on computer science, I learned more about lisp and its integration in emacs. At that point I decided to try it out. I wanted the full experience, to be able to form an honest opinion. So, I forced myself to do an entire course using emacs instead vim. No evil, just plain emacs. During this time, I fell in love and never looked back.

I still like vim, I just don't find any use for it anymore, except quick editing on servers. Knowing vi key bindings is useful, as vi is almost always present. However, I think that known/understanding emacs key bindings is underrated. Understanding the logic of emacs key bindings will not only makes you more proficient at handling emacs, it also makes moving around most shells more efficient. I know you can configure shells (or more specific: readline) to use vi key bindings, but the default is emacs!

My advise in learning emacs would be: dedicate some time on using it for something real. I'd say, don't get too tempted by the vimify plugins, as they will hide some of the logic of how emacs works. This might slow down or dumb down the learning process. But I'm not discouraging the use of vim plugins all together, just make sure you understand the core product, before modifying it beyond recognition.

I was in exactly the same situation you're in. Wrote about this a while ago: https://rohitpaulk.com/articles/vim-to-emacs.

Took me a couple of weeks to acclimatise, but overall the switch was worth it. If you haven't tried it yet, I'd suggest Doom over Spacemacs (details in the article).

For me the thing is that emacs can be overwhelming. So focus on doing one task at a time. I still don't know the whole spacemacs interface. I know where my major mode keybinds are. I know how to deal with my .spacemacs. I know where to find documentation. I deal with everything else on a case by case basis.

Here's a getting-started post I wrote when I switched from Vim to Emacs.

https://fnune.com/2017/12/27/making-emacs-work-like-my-vim-s...

Since then, I'm back to using Vim. I'm planning to write about that, too...

1. You have to get comfortable editing your own config, as much or even more than editing your own .vimrc. I don't think you have to become a lisp master, just understand what is going on like you probably do with vimscript.

2. Consider using Doom Emacs as a starting point. It's fast and works like you would expect out of the box. You can use it like Vim and discover aditional features as you need them. And most importantly, it's (almost) as easy to configure as vanilla.

One of the easiest ways is to start using emacs for something you didn't use vim for before, like org-mode. Or just for magit, but not text editing yet. Either way, you can stay in your fast, happy path in vim as long as you like, and trickle in small edits in emacs until it becomes more comfortable.

So you can avoid the heavy slam of new-editor-awkwardness in your important work.

I do recommend spacemacs, it (looks like, I'm vanilla emacs myself out of habit) has many packages and customizations atop of a vim-ish keybinding.

I’d recommend Doom Emacs over Spacemacs for a few reasons: Spacemacs tries to be everything-for-everyone and it is far too dense for someone trying to learn Emacs. Evil-mode is its “killer feature” but that’s available without Spacemacs. Doom Emacs is more like Vanilla Emacs with an obvious lean towards evil-mode. It comes with sensible defaults and loads up so much faster than Spacemacs does.

I used vim and vi for about 25 years before switching to Emacs. I had many thousands of lines of configuration in my .vimrc that I needed to port over, because I didn't want to lose any functionality over vim.

It took a really long time and a lot of effort to get Emacs to do everything that I could do with vim, but I finally did it, and now Emacs does not only pretty much everything vim ever did for me, but does a lot more.

I don't regret the switch or the time and effort it took in the slightest. However, there are a couple of things I do miss about vim and occasionally even fire up vim for.

One is the inferiority of Emacs' regex engine, in certain important respects, like \zs and \ze in vim, which have no Emacs regex equivalent. Those patterns let one match on the beginning or ending of a regex pattern while leaving the position of the cursor/point somewhere else and highlighting a subset of the entire match. That can be pretty useful in certain situations, but it's not enough to leave Emacs and go back to vim.

Another aspect where I find vim superior is in handling large files and files with very long lines. It's just way more performant than Emacs in those situations. Emacs does have long-lines-mode, but it's a hack, and doesn't work in dynamic buffers (like shell buffers) anyway. For handling such files I sometimes temporarily switch back to vim, and back to Emacs after I'm done with that file.

Other than that, there's really nothing about vim that I miss. Though, since I've left vim I have heard that neovim has achieved integration in to various IDEs and other apps that I wish Emacs had.

Anyway, back to the original question about tips for someone else making the transition from vim to Emacs: Apart from perseverance and the use of evil, I'd suggest making hydras for every major mode that you use. That's made Emacs way more useful for me.

Oh, and learn eLisp! If I hadn't known and loved Lisp, I would not have switched from vim to Emacs. There's just no way I could have ever configured Emacs to have all that vim-like functionality (and more besides) if I hadn't known eLisp and actually enjoyed using it.

That Emacs itself and the entire Emacs ecosystem was written in a Lisp was actually a major draw for me to make the switch from vim to Emacs, and in fact it is what's made writing that mountain of configuration not only bearable but actually fun and interesting.

If you hate Lisp, stay far away from Emacs. If you like Lisp, run to Emacs! :) If you don't care one way or the other, give Lisp and Emacs a try.. you might learn to love them, like I do.

Perseverance is the name of the game, much like it is in everything else we do.

I’ve been learning Vim and Emacs concurrently with Doom Emacs. I find that if I don’t use the tools for actual work, where speed/familiarity is necessary, I become acclimated to the new environment and start transitioning to its use full-time. Just editing configs is enough to get familiar and it’s low-stakes as far as fucking things up goes.

As others have mentioned, `C-h t` should be enough to get you comfortable using it as your daily driver. From there the sky is the limit!

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.

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

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.

It has saner defaults for a lot of workflows. Two small examples: stashing prompts you for a name (instead of defaulting to a useless name), and commiting will show the diff of what you're committing on the side (similar to commit -v).

It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.

Not a Magit user, but vim-fugitive. The main reason I prefer it over the CLI is for (un)staging hunks or lines. But I still use the CLI a lot for other stuff.

Are you in windows by any chance? Magit is crazy slow on windows because of it's interaction with git, which is very quick on linux. I started trying it on windows and couldn't see why people would use it, and now that I'm on linux I have no problem with it.

I use both magit and git cli now. Magit is great to get an overview of the changes, the main view is very interactive which is great (e.g. chunk or even line by line staging/discarding/etc. is great)

But to each their own of course.

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.

Picking hunks for resolving merge conflicts is far easier in Magit than using the CLI. Obviously you’d normally do the latter in an editor anyway, but since you’re already /in/ your editor it’s then seamless to continue the merge from within the same environment, instead of bouncing back and forth between the CLI and your editor.

Rebasing in Magit is very straightforward, far easier than faffing about with the git CLI. Even more so if you’re re-ordering commits, or editing things mid-rebase.

Those are just two obvious things off the top of my head. Magit is pretty great.

I would never want to go back to the original CLI.

I'm constantly doing things like reverting single hunks, applying and saving stashes, looking at a stash and applying a single hunk from there, staging hunks into multiple commits — all of this is much quicker with Magit. It changed the way I use git.

If all you do is simple commits, branch checkouts and cherry-picks, you might not need it. But there is so much more to Git, and Magit makes it nice and quick.

Magit is faster, as in pressing r i in magit's buffer does you an interactive rebase where you can choose the commit to start from. After picking that you can c(= pick)/w(= reword)/m(= edit)/k(= remove) commits from the list.

Another thing that is convenient is that you can add files to index by selecting lines in a hunk. Doing that in bash is perhaps not as easy (or if it is, do say how).

These are just a few examples. But in summary, magit is just a "tree of keyboard shortcuts" where you just click a few keys in sequence to get what you want.

That said, I also use the cli a lot, i.e depends on if you're in emacs already, or not.

Mostly because I don't have to tab out to a terminal, which then yanks me back into the commit message text editor anyway.

Also because "c c" is faster to type than "git commit" and "s" is faster than "git add filename.foo".

How do you do partial file commits with the CLI? E.g., commit one hunk in a file but not another? (Theoretically, you can do this with `git add -p`, but I’d say that’s a comparable downgrade from a GUI like Magit to using `ed` as a text editor is today.)

It’s also just silly to view a multi-file diff, which is hierarchal (File > Changes) just as a flat terminal dump. It's fine for quick diffs that follow a simple pattern, but I wouldn't want to review a complex diff that way.

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.

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.

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

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.

magit lets you stage each hunk, or if you want finer grained control, simply select the lines you want to commit or exclude and it will just stage / unstage those lines.

It's better than editing a patch file; it's much better than `git add -i`.

Sublime merge looks great, but it costs quite close to what I would be paying for a full IDEA licence yearly: $100? This is ridiculous.

It's a one time fee and IMHO is totally worth it.

Sublime Text and Sublime Merge are works off art in terms of speed and usability.

Although I tend to use vscode more now for editing, I use Sublime Merge every day at work. Worth every penny.

It is ridiculously expensive, until you realize that a professional software engineer quite often cost a company more than $100/hour

You don't need to own this program for long, before it has saved you more than an hour or 2 of work. And the fee is not recurring.

Now, convincing management that this is a good investment, is of course a completely different story :)

Not sure about other editors, but Magit's hunk- and line-level staging/unstaging is hard to beat, IMO.

For hunk-level staging, you put your cursor on the hunk you want to add and press "s". If you want to split that and only stage a few lines, you just select those lines and press "s".

This demo is pretty good I think: https://www.youtube.com/watch?v=rzQEIRRJ2T0

And of course you can select an arbitrary region to stage if you like.

I regularly use git add -p. Also git rebase -i.

I get the feeling that people don't really know about the interactive git commands.

TBQH most people don't explore git beyond the pull-add-commit-push flow, the ones that do immediately feel like they need a GUI where a TUI would do just as well.

Oh, talking about TUI, I also use https://jonas.github.io/tig/ sometimes.

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.

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

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

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

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.

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.

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.

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.

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

I've been using a Vim clone of Magit for a while with good success: 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.

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.

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

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/

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

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

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

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

Insanely powerful.

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.

Add to that that the page failed to make any attempt define what was meant by porcelain.

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.

Reply on news.ycombinator.com