Magit(magit.vc)
magit.vc
Magit
https://magit.vc
43 comments
I just joined you as a supporter, thanks for the nudge
Yup, this is probably one of my biggest product boosters in the toolkit. Using the Vscode extension version since I just fully migrated to IDE-land (emacs too slow on big monitors), but still fantastic.
How does the size of your monitor relate to the speed of emacs?
> Using the Vscode extension version [...]
Are you referring to https://github.com/kahole/edamagit ?
Are you referring to https://github.com/kahole/edamagit ?
I'm surely in the minority here. I've been using Emacs for almost a decade now, but I just can't get into the Magit workflow. I've tried several times, but always end up going back to Git on the command line. I have dozens of aliases, shell integrations, a nice diff viewer[1], etc., and interacting with Git has become muscle memory. I can commit, cherry-pick, rebase, bisect, fix conflicts, etc., in a fraction of the time it would take me to navigate Magit's UI. I'm sure with enough practice, a Magit user could do this more quickly and efficiently, but honestly, with some custom-built porcelain, Git's UI is not so bad. Though this could very well be Stockholm syndrome after using it for such a long time...
For whatever reason, Magit's opinionated workflows never clicked with me. A part of it is the concern that it will do something weird to my repo that I'll then have to waste more time undoing manually. I usually don't trust sugary wrappers around tools. And another is the fact I don't use Emacs on all machines, and setting up Git on a remote system is just a matter of copying over my config and some shell integrations.
Also, on a more personal note, I find the cultish fanboyism whenever Magit is brought up slightly offputting. Does anyone have anything bad to say about it? No software can realistically be this infallible. :)
[1]: https://github.com/dandavison/delta
For whatever reason, Magit's opinionated workflows never clicked with me. A part of it is the concern that it will do something weird to my repo that I'll then have to waste more time undoing manually. I usually don't trust sugary wrappers around tools. And another is the fact I don't use Emacs on all machines, and setting up Git on a remote system is just a matter of copying over my config and some shell integrations.
Also, on a more personal note, I find the cultish fanboyism whenever Magit is brought up slightly offputting. Does anyone have anything bad to say about it? No software can realistically be this infallible. :)
[1]: https://github.com/dandavison/delta
I mainly use magit for reviewing changes, staging and committing. I haven’t found an interface that compares for staging and discarding hunks. But checking out branches I do on the command line and I use Meld for resolving conflicts.
> But checking out branches I do on the command line
Just in case you have a longer workflow, checking out a branch should just be `b b` and then select the branch from a list with typing or up/down.
Just in case you have a longer workflow, checking out a branch should just be `b b` and then select the branch from a list with typing or up/down.
And if you use a narrowing framework like consult+vertico+order less you can select the right branch super quick.
Yeah similar, magit has never felt intuitive to me. FWIW, I have Emacs open in one terminal and lazygit open in another, with lazygit using Delta.
> A part of it is the concern that it will do something weird to my repo that I'll then have to waste more time undoing manually. I usually don't trust sugary wrappers around tools.
You can easily look at magit's process buffer with $ to see got commands run.
Magit is also good about not running more hit commands than necessary unlike other porcelains.
You can easily look at magit's process buffer with $ to see got commands run.
Magit is also good about not running more hit commands than necessary unlike other porcelains.
In my experience it's pretty rare that a frontend comes along and fundamentally changes my workflow around the underlying tool, but Magit falls into that category for me. Truly a great piece of software.
I love magit and I use it basically every day. But lately, at my work's monorepo, I've been greatly pained by how synchronous it is (like much of Emacs). When I want to fix a unit test, I find suspicious commits by a grep for some keyword through diffs in the git log, and unlike the git CLI, magit will not show me any matching commits until it has searched through all of them (capped at 256 matches by default), which takes a very long time. I love so many creative Emacs tools, but the wait times from magit and consult get painful.
I'm starting to feel the pain too, and we're not even at a monorepo stage - just a large project with lots of history.
There's some interference coming from me running Emacs/Magit on WSL1, and corporate nuking my Windows Defender exclusions lists, meaning "real time protection" is slowing every file write down. Still for small to medium repos it's wonderful; for that one large at work, it's... pretty much setting my tea breaks.
Currently the most annoying mysterious issue is that some commands (usually pulling or rebasing, sometimes committing too) reach the point of Magit echoing "git finished", and then... whole Emacs remains frozen for 30-120 seconds. I haven't traced that tone to source yet.
There's some interference coming from me running Emacs/Magit on WSL1, and corporate nuking my Windows Defender exclusions lists, meaning "real time protection" is slowing every file write down. Still for small to medium repos it's wonderful; for that one large at work, it's... pretty much setting my tea breaks.
Currently the most annoying mysterious issue is that some commands (usually pulling or rebasing, sometimes committing too) reach the point of Magit echoing "git finished", and then... whole Emacs remains frozen for 30-120 seconds. I haven't traced that tone to source yet.
> Currently the most annoying mysterious issue is that some commands (usually pulling or rebasing, sometimes committing too) reach the point of Magit echoing "git finished", and then... whole Emacs remains frozen for 30-120 seconds. I haven't traced that tone to source yet.
`M-x toggle-debug-on-quit` and `C-g` during the freezing will probably help here, though I would guess the problem is highlighting since that tends to take a lot of time on big diffs.
`M-x toggle-debug-on-quit` and `C-g` during the freezing will probably help here, though I would guess the problem is highlighting since that tends to take a lot of time on big diffs.
> There's some interference coming from me running Emacs/Magit on WSL1, and corporate nuking my Windows Defender exclusions lists
In my experience this brings emacs to a crawl.
In my experience this brings emacs to a crawl.
If you’re interested, you should take a look at Sublime Merge. I switched to it a couple of years ago. Made by the creators of Sublime Text so it’s as snappy as you’d expect. And it has some surprisingly powerful tooling when it comes to searching the history (list all commits that changed a file and by a certain author etc). I also like that you can see a log of all of the git commands it’s executing behind the scenes.
I had a brief and rather complicated affair with Emacs some years ago. I tried Magit then. It was ok(ish), but could not understood what all the fuss about. Sublime Merge is so much better -- blazing fast and designed so well. Perhaps I'm not objective here, since I'm also a die-hard fan of Sublime Text -- the best editor for writing research notes, papers, prose, and code :)
At work I go back to using the command line too and use emacs to edit the commit messages.
I find it's not only magit that's not ready for huge monorepos. I had to maintain a huge directory blacklist before sparse clones were supported internally (before everything pretended to be around and was streamed/cached underneath, which tripped every regular tool into fetching too much)
Love magit. I recommend using it with magit-delta https://github.com/dandavison/magit-delta for the syntax highlighting.
magit-delta's dev is very responsive, but there's still an outstanding performance issue blocking me from adopting it:
https://github.com/dandavison/magit-delta/issues/9
https://github.com/dandavison/magit-delta/issues/9
For neovim users, there's a work-in-progress clone, neogit: https://github.com/timUntersberger/neogit/
Some of my colleagues use emacs/magit, and after seeing how absolutely lovely the workflow is, I've put in a lot of work over the last few months expanding it. You can check out my fork here: https://github.com/ckolkey/neogit/
One thing I particularly like to tease my emacs' colleagues about is that my magit is faster than theirs thanks to neovim's async capabilities.
Some of my colleagues use emacs/magit, and after seeing how absolutely lovely the workflow is, I've put in a lot of work over the last few months expanding it. You can check out my fork here: https://github.com/ckolkey/neogit/
One thing I particularly like to tease my emacs' colleagues about is that my magit is faster than theirs thanks to neovim's async capabilities.
> One thing I particularly like to tease my emacs' colleagues about is that my magit is faster than theirs thanks to neovim's async capabilities.
emacs has async i/o as well, it's just not used very pervasively.
emacs has async i/o as well, it's just not used very pervasively.
Are you referring to process sentinels?
https://www.gnu.org/software/emacs/manual/html_node/elisp/Se...
> emacs has async i/o as well, it's just not used very pervasively.
The most notable exception I can think of is elfeed which works very smoothly.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Se...
> emacs has async i/o as well, it's just not used very pervasively.
The most notable exception I can think of is elfeed which works very smoothly.
I got so used to staging individual lines instead of files — it’s so much more intuitive! With „s“ and „u“ I sift through my edits and discard any debug code that I haven’t checked-in accidentally for a long time. Magit also speeds up cycle management of dev branches so much. It‘s usually just a couple of single key strokes — pretty cool.
But I would say, you really have to have drank the Emacs Koolaid to appreciate Magit‘s greatness.
That being said it’s only after I discovered Magit I also started to appreciate Emacs‘ built-in version control mode: The same key combo „C-x v n“ (Versioning Next step) does initialize a repo and checks in files with any kind of backend (be it git, mercurial or subversion). That’s pretty neat, too. With „C-x v l“ I access „git log“ for any file where I can access diffs or visit an older version of the file in a separate buffer e.g. to try out an older implementation of a function. „C-x v g“ gives me a „git blame“ integration jumping straight to the line I was hovering on.
So for exploring git logs I am using vc-mode but staging and branching I am leveraging Magit. They complement each other well.
But I would say, you really have to have drank the Emacs Koolaid to appreciate Magit‘s greatness.
That being said it’s only after I discovered Magit I also started to appreciate Emacs‘ built-in version control mode: The same key combo „C-x v n“ (Versioning Next step) does initialize a repo and checks in files with any kind of backend (be it git, mercurial or subversion). That’s pretty neat, too. With „C-x v l“ I access „git log“ for any file where I can access diffs or visit an older version of the file in a separate buffer e.g. to try out an older implementation of a function. „C-x v g“ gives me a „git blame“ integration jumping straight to the line I was hovering on.
So for exploring git logs I am using vc-mode but staging and branching I am leveraging Magit. They complement each other well.
I've been using lazygit and it's amazing. I used to use magit and I think it's great but lazygit seems to have an easier learning curve and is trying to accomplish the same thing (easy reach to the most common git actions).
I'd like to plug [tig](https://github.com/jonas/tig) for those who don't use emacs. I see lazygit recommended here too, but I've been using tig for years now and love it's simplicity.
I just adopted lazygit after comparing lazygit, tig, and gitui for a few days each. I’m surprised by your take because tig seemed the least user friendly and most complicated of the three by a large margin.
Magit made git usable for me. It's both intuitive to use and powerful (at least compared to my needs).
How to pronounce it? Any way you want, it seems. https://magit.vc/manual/magit/How-to-pronounce-Magit_003f.ht...
Ma-git. The second syllable like gif.
I switch between magit while on emacs/coding and lazygit while on terminal... I love them both for staging/amend/cherry-pick etc....
I’d heard it was worth it even if you don’t use eMacs. Spend half a day trying to figure out how to install and just gave up.
What I do is:
1. Install Emacs
2. Install Doom (git clone + run a command): https://github.com/doomemacs/doomemacs
3. space g g to invoke magit
1. Install Emacs
2. Install Doom (git clone + run a command): https://github.com/doomemacs/doomemacs
3. space g g to invoke magit
You "apt install emacs elpa-magit". Your OS should respect you enough to make it this simple.
It is worth it imo. there is a caveat that you will have to learn a little bit about emacs to effectively use it if you accidentally do something that throws you into a buffer(file). you need to be able to navigate and delete buffers and frames. if you know vim bindings and install doom emacs it helps a bit too since emacs commands are a bit inscrutable and hard to configure well without it.
i don't use emacs as a daily driver anymore but i solely use it for my git stuff.
i don't use emacs as a daily driver anymore but i solely use it for my git stuff.
Magit is one of the two software packages known to make non-Emacs-using people install Emacs only for that package. The other one is Org Mode.
I love that use of the VC domain. Refreshing.
There's a great magit plugin for VS Code: https://marketplace.visualstudio.com/items?itemName=kahole.m...
BTW, if you use and appreciate magit, please subscribe and contribute financially (yes, I do that). We shouldn't expect great tools to be maintained and developed for free.