I've never seen the upside. I use Emacs as my primary editor, and I regret it every time I say "today is the day I start using Magit". It is exceedingly invasive, triggering itself even when you don't ask for it (like running "git rebase -i" on the command line). The invasive stuff changes how the text editing itself works, but doesn't add deep features. In the interactive rebase case, I lose the ability to treat the interactive rebase text as text, but I also don't gain anything. I can't just navigate around, kill a line, and put it somewhere else. Well, I can do that, but the usual keybindings don't work, they just made their own for no reason. And, for example, if I do use their UI and pick "reword" as the operation for a certain commit, I should be prompted for the desired rewording then and there, right? But that's not what happens, I press C-c C-c to commit my changes (why isn't it C-x # which is how I'd normally close an emacsclient session?), then Emacs goes away, then it comes back up, then I can type my rewording. If you pick it more than a few times, you just get a seizure from all the flashing lights. This isn't a good user interface. It's a bad user interface.
Obviously, my experience must be unique, because everyone loves Magit. It might be the most-loved piece of software ever. Every other week, there is an article on Hacker News about how it's the best piece of software ever to exist, and I've never seen anyone say anything bad about it. So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared.
Maybe there is some fundamental insecurity about Git, and Magit makes people comfortable? I've never felt that way, but I did start using Git the weekend it came out, and my Github user ID is in the low 2000s, so I might have had time to get Stockholm Syndrome with the Git UI. I suppose it's possible that the people writing these articles may not have even been born when Git came out, which is interesting to think about actually!
> So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared.
It's easy. 1) Listen to the fans when they suggest a feature even if it doesn't click when first hearing about it, but then approve upon the initial suggestion, turning it into something I myself would want to use too.
2) Ignore the haters except for telling them how to disable that one feature that is so abhorrent it makes the whole tool unusable:
Let me rephrase that: Give those that already love your project more of the same instead of wasting time on making those who think your approach is fundamentally misguided slightly less dissatisfied.
Using git for so long is almost certainly what’s up - you not only know all the various commands but “grew up” with git so you didn’t get them all in a rush.
Many many people use git as cvs and are confused once it goes past “commit and push”.
I know I don't really know what to do if someone pushed to master whilst I was working and it complains. Usually I just make a new checkout and merge in by hand.
I knew git at a deep level before picking up magit and I can’t disagree more with how you paint magit. Magit is the one and only git GUI that actually aligns with the git CLI and doesn’t present git as just another VCS like perforce.
I know immediately what magit is going to actually do when I use it. I could easily do everything in the terminal but I don’t because magit lets me do things so much faster and with fewer keystrokes.
Interactive staging of hunks in magit is far superior to doing the same thing with the CLI. Making interactive staging easier helps prevent hunks from ending up in the wrong commit. Oftentimes 2 different parts of a changed file in the worktree should not be in the same commit, so being able to stage hunks lightning fast in emacs is a game changer.
Here is an example of what I would do in magit with spacemacs which has evil-magit
SPC g s — pulls up magit
Tab to expand a file
s to stage
c c to commit
l L to see a detailed graph of all local branches
Move cursor to commit I want to cherry pick
A a to cherry-pick commit that my cursor is under
p p to push my branch to remote
When I’m deep in work it’s so incredibly lower friction to do that sequence of actions in magit than using git CLI.
Sure I’ll still drop down to the real thing if I need to do some really esoteric spelunking through the repo with plumbing commands but if I’m already in emacs magit is amazing.
Just to clarify, does emacs/magit really pop up when you run "git rebase -i" on the command line? I haven't experienced this, but maybe that's because my EDITOR env var is set to "vim". I would find that very annoying.
I like magit, but I never figured out the rebase flow with it, so I just do that on the command line.
Where magit really shines for me is being able to stage and unstage hunks of code very easily. Looking at my current changes, stashing and un-stashing, searching through git log, seeing the diff of a particular commit, quickly fetching from upstream or switching branches... All of that becomes quick and easy once the key bindings become second nature. There are definitely major quirks of the UI / UX, but I found it worth fighting through that.
edit: I've re-read your post again, and I would just like to reiterate that staying away from magit's interactive rebase might be a good idea. Besides that, I also try to stay away from triggering ediff mode -- even after spending time with it and getting to know how it works, I've decided that it's simply not very good.
> Just to clarify, does emacs/magit really pop up when you run "git rebase -i" on the command line? I haven't experienced this, but maybe that's because my EDITOR env var is set to "vim".
It would only pop up from running `git rebase -i` (or whatever) if your $EDITOR is set to emacs. I'm a heavy emacs/magit user, and even I find the idea of setting my $EDITOR to `emacs` abhorrent.
Magit's log command made my Doom emacs unresponsive for hours, after which my patience gave up and I killed it and restarted. I guess it just doesn't work on larger repositories.
> , because everyone loves Magit. It might be the most-loved piece of software ever. Every other week, there is an article on Hacker News about how it's the best piece of software ever to exist, and I've never seen anyone say anything bad about it.
> So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared
Ah, you've lost me. Why are you dismissing the other possibility that you have bad judgement?
Some tools inspire reactions like this. Nix and NixOS also fall in this camp. The small number of people who love them write blog posts and comments evangelizing them. The much larger number of people who find no use for these tools, or who tried them and do not like them, do not find it worth the energy to write something about why they did not like the tool or why they just never bother to try it. Even if they did write something, it wouldn't get upvotes - "I tried this Magit thing, and it's supposed to be better than vanilla git, but really it isn't, so I keep using vanilla git," is just not an interesting blog post.
So yes, most Git users are just like you and see no upside to Magit. Call it the silent majority.
For your everyday stage->commit->pull->push I think magit is damn near perfect. Staging individual files, or even individual blocks is simple and not verbose (unlike cli equivalents). Picking out eg. problems with my gitignore I find to be easier while looking at the magit status page as well. I think conflict resolution also bears looking at.
For other things... you'd have to ask somebody else. I generally do any type of branching or merging or similar using the git cli, and that's part of the beauty of magit: she doesn't care when I cheat on her that way.
Ah, for me it doesn't invade the command line at all, perhaps because I don't have emacs set as $EDITOR?
I use emacs as my daily driver also, however if bash wants an editor it's usually a small task, so I'm just as happy to use vim or nano. Most often I can't install emacs on remote servers anyway.
Why would you run "git rebase -i" from the command line if you have magit? It's cool that it works, but it's far from normal. Just do it with magit and you won't get the "flashing lights". The rebase workflow in magit is one of the best parts.
I like magit because it stays very true to Git's native theory of operations and is much quicker. I'm an evil/Spacemacs user and the bindings make sense to me. Marketing has nothing to do with it.
C-c C-c is a natural "do it" binding in many emacs dialogs, as opposed to C-c C-k. I understand you might prefer C-x # if you often use emacsclient as your EDITOR, but I would venture to say that most people might not.
Obviously, my experience must be unique, because everyone loves Magit. It might be the most-loved piece of software ever. Every other week, there is an article on Hacker News about how it's the best piece of software ever to exist, and I've never seen anyone say anything bad about it. So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared.
Maybe there is some fundamental insecurity about Git, and Magit makes people comfortable? I've never felt that way, but I did start using Git the weekend it came out, and my Github user ID is in the low 2000s, so I might have had time to get Stockholm Syndrome with the Git UI. I suppose it's possible that the people writing these articles may not have even been born when Git came out, which is interesting to think about actually!