I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here.
Tig for example is so much faster for history and blame perusal that I find it faster to keep it open in another terminal and just switch to it.
Altenatives? Contrarians?
I prefer IntelliJ's git interface.
Magit can do everything IJ can, but in IJ, I can find how to do things more easily and it just feels easier to do things, probably because it's much more GUI than text compared to Magit. For example, difficult merges are extremely easy in IntelliJ, I can edit code in the diff view itself while I resolve conflicts... in Magit it requires getting used to the different diff views, something I am still trying to figure out, but it seems trickier to do "in-place" changes in the code.
That said: I probably only prefer IJ because I've been using it much longer than I have used Magit... and the difference for me is very small, so I suspect the more I use Magit, the more the gap will close and I may eventually like it even more than IJ.
Not the biggest deal since neither of those commands require interacting with the output which makes them equally easy to run from the terminal, but it's strange that they're not available in an immediately obvious place.
In the lower right, there's the vcs "where you're at" that shows the current branch. From there you can see the status of your branch compared to others (if you need to fetch them), or you can update branches (even those you're not currently on) along with branch specific operations including push. You can access the same in the git panel with right clicking on branches in the log.
At any time, you can double tap shift to bring up the "search everything" window. Within that, if you type "git push", it will display that action along with the menu that action is in and any key shortcuts that are bound to it.
Also, glance under the "Help" menu - there's a productivity guide. That shows you a whole bunch of features (and how often they're used) and how to use them.
Maybe you disabled the git toolbar in the menu?
There's a little bit of discussion on it.
Its UI for resolving merge conflicts is so intuitive and powerful. You get 3 panels: local changes on the left, remote changes on the right, and merged in the middle. It's got colored highlighting going across from each of the side to the middle, showing where the changes want to go to, and you click arrows to accept/dismiss left or right, and sometimes it'll even have a suggestion for a way to take both of the changes (indicated by a magic wand). And you can also just type into the center editor if you want to not use either side, and manually rewrite the resolved change yourself, whether that be copy-pasting from each side or whatever you want to do.
It's saved me so many times, it's practically worth the cost of the entire IDE on its own.
- I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed. First thing I do on e.g. a new cloud instance is clone a bunch of stuff, and often work on an under-setup machine for a while. For similar reasons, I don't use shells like Fish, which, nice as they may be, funnel me into something totally incompatible with good old sh. Bash and zsh, as far as I use them, are compatible.
- I work in tmux, and emacs in terminal, the overhead of switching to a terminal and typing some git stuff is tiny.
- I tried magit and just didn't get it. I couldn't couldn't find a happy path where I thought, "ah yes this is niice".
I mostly use plain git instead of Magit, for more or less the same reason, although I like git's UI.
I did find a happy path, though. Magit's blame interface is very nice to recursively call git-blame and navigate history of pieces of code. I ended up making a CLI program to improve git blame[1] so that I didn't end up switching to Magit just for that, but doing git-blame from Magit is still better.
I'm surprised to hear this. Magit is a very thin layer on top of git. Not thin in the technical sense, but in UI/UX sense. Keybindings map almost one to one with git CLI. Arguments to the git CLI are explicitly stated. Executed git command is reported. I learned git better by using Magit.
FWIW, most Magit commands have 1:1 correspondence with git commands; when I'm worried I'm doing something with Magit that I wouldn't be able to replicate with CLI, I just press '$' to pop up the "process buffer", i.e. the buffer containing actual git commands being executed, along with their output. Conversely, I still read git documentation to figure out more advanced Magit workflows.
My way of looking at it is, Magit is just an ergonomics layer on top of git - it doesn't introduce new abstractions, it just lets you do stuff in a more efficient and interactive way. The love comes from that efficiency - the improvement is big enough to make a qualitative difference and affect the way I interact with git.
(And, of course, you can just press !! and type in whatever git CLI command you want, to run in context of your repository.)
> the overhead of switching to a terminal and typing some git stuff is tiny.
Switching cost is low, but typing cost is much greater.
Of course, everyone has their own preferences. I personally swear by Magit, and I'd love to have more command line tools be integrated with equivalent interface. Magit's UX paradigm isn't a total replacement for all CLI - but it's perfect for tools you repetitively invoke with different parameters to sculpt something.
That typing cost is why I use a GUI. While many times I can just enter `git add -u` into the terminal, there's still plenty of times where I want to be selective about what goes into the commit. If a simple glob pattern can't do it, then I'm going to reach for the GUI where I can just click on all the things I want to add to the commit in far less time than it would have taken to type all of the file names.
The GUIs also keep me immediately informed on the state of my repo. On the terminal, I'll be running `git status` a lot, just to be sure the state I think the repository in in and the actual state match up.
The popup-based paradigm for keyboard operation helps with discoverability - first few times around, you'll be going slow to learn what key does what, but after that, you'll be issuing most commands from memory.
The key point I was trying to make is that an interface that minimizes the amount you need to type out and that gives you instant feedback to your actions is a superior experience for working with Git in many cases. I say this as someone who uses Git from the command line a ton (to the point where I've added some custom command scripts) but then when I need to do anything complex or browse the logs and diffs I'll enter `gitex` to bring up the Git Extensions GUI.
That said, I’ve financially backed Magits development (Kickstarter iirc) and I use it almost everyday, but I don’t do merges with it. I’ve had some large merges go really slow thru Magit. So I always do my merges in the terminal using the plain git CLI.
Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening.
Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option.
I only work on Emacs in small projects though... so maybe that's why it's fast for me?!
I believe these days (i.e. since emacs 25) it can via dynamic modules. There are ffi libraries built on top of it.
In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.
Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.
Seems like there's something going on in the windows world.
However, my own cited example about browsing history and blames is one case where I cannot just stomach the subpar efficiency. Tig also runs git as a subprocess, but every view is truly incremental and you can scroll through any buffer in any view and there's absolutely zero delay. Night and day even when comparing emacs with JIT.
Like for magit, tig has one keystroke shortcuts that make sense (which IMHO is pretty common on good TUI programs) and can perform many git operations directly from the spot you're looking at.
I also consider the visual space usage in tig to be much more efficient as well. Especially the blame view, which I find still wasteful in all modes compared to tig's. I frequently use a customized vc-annotate instead.
Magit hooks also considerably slow down operations on remote files, which can be quite annoying if you don't actively need to use git while editing.
Don't get me wrong - I like magit. But like org-mode, I don't get the glorification it gets.
It's very cool and flexible and doesn't tie you in to any big tech provider (yay!), but it's just an outliner at the end of the day.
Sublime Merge and vscode + git plugins are pretty close to each other but Sublime Merge does everything I need with less fuss. vscode just has some rough edges due to it's swiss-army knife approach that Sublime Merge doesn't.
While working on kernel I sometimes get "looks nice, but can you reorder and re-split this 15-patches series in completely different way?" and magit is a big time-saver for that. It wasn't as useful on my previous jobs where 1k-lines commits with message like "Implement feature X" were the norm, though.
interactive rebase: no
cherry-picking: yes
I will say that I won't be using it, as I use GUI tools, with a far smaller "power" level, and use command-line Git for the few times I need anything fancy.