A walk through the Magit interface

It's actually `git commit --amend --no-edit`, but yes, it's basically "just" a shortcut. Count the keystrokes, though. If you spend much time working with git it's a huge win.

Of course you could do something similar with shell aliases or reverse search, but then there are other switches and flags that you need occasionally, etc. And it's sooo much more convenient to have everything in one place right in your editor. It's almost unfair how much faster I can get stuff done than folks who don't use it ;)

Magit isn't hype, it's as good as everyone says it is. You just have to try it.

> Eventually I decided that the sheer number of magic incantations I had to remember to do anything useful wasn’t worth it

Isn't that the point of Magit?

People who never tried Magit often say either of these two things:

- "I'm already an expert in Git, I'm fine with the command line", or

- "Git is confusing already, I don't want to learn yet another thing"

The main point about Magit (unlike many other Git GUIs) - is to help you discover Git features, and allow you to do your work in a very efficient and simple workflow. However, it would do so without hiding Git mechanics from the user. Anytime you can check what the actual Git command gets executed.

Magit doesn't liberate you from learning Git internals, but at the same time it doesn't overwhelm you with tons of different command-line switches. You don't have to memorize anything, the reference for all the commands is always available to you.

I believe, I have become a Git ninja because of Magit. Without it, who knows, maybe I would never learn many features of Git.

Well, I could say "sure, here's my config * ", but all that I described may not be very simple and straightforward (especially for a beginner). For example: we use Jira at work and I can't stand it. I use go-jira command line client and "talk" to Jira from Emacs via that tool. Meaning that I had to configure go-jira and write some emacs-lisp code that executes it and then parses json, etc.

Also the workflow I described is not completely automated yet, I'm still experimenting and it's not very clean - things right now are scattered across different config files.

If you have any questions I would gladly try to answer them in a private chat: either email, twitter, signal, telegram or keybase. Let me know.

* https://github.com/agzam/dot-spacemacs

> Same but one caveat that still bothers me about it is that it's not a scriptable package.

What are you talking about? It's written in Emacs-lisp, the possibilities are virtually limited only by Emacs's capabilities. Explain what you're trying to do, maybe post your problem to emacs.stackexchange, r/emacs. I'm sure people would be able to help you.

It's okay. Every time there's a discussion about Magit, people bring their favorite Git GUI to tell everyone how stoked they are to use it. I myself have tried several of them. However, majority of those apps are like Steve Yegge would put it: "are cookie-cutter solutions". Whenever you need a quick way of doing something that's not built into the tool, you have no option but to submit a feature request and wait. Sometimes wait for a very long time. With Magit you can just do it yourself. Emacs lisp is not super difficult to pick up. Besides, there are bunch of forums where people would happily help you.

One small example: I needed to see log of commits since the last pull, basically `git log ORIG_HEAD..HEAD`, but in a way that's compatible with Magit, otherwise I would just do it in the command line. It's not something that people would do very often, it's not usually built into the client. To get something like that to work with Magit, literally takes a single line of emacs-lisp.

It is true that other tools have most if not all features of Magit. But I doubt there's a single tool that comes with all of Magit's features.

Sounds like you haven't used Magit very much. Browsing the manual for a few minutes, or looking at a screencast or YouTube video, would show you how much more Magit does than what you described.

Regarding commit-patch specifically, its readme says that, to commit parts of a patch in separate commits, hunks must be "killed, split, or edited" into separate patches.

Magit is obviously superior to that: with a few keypresses, hunks in the working tree can be staged, hunks in the index can be unstaged, etc. Unstaged changes in the working tree can quickly be sliced and diced and committed separately. Individual lines can be staged or unstaged by selecting them visually. Magit can even automatically back up changes at each stage of the process into special branches, so if you realize, hours or days later, that you accidentally discarded some code without committing it, you can easily retrieve it.

Magit is the most powerful, efficient version control tool. See for yourself: https://magit.vc/

> the only extra thing magit does is rebasing

You have no idea on how many levels that statements is false, there's much more than just the rebase:

- You ever needed to see branches in a specific order, sorted by committer-date?

- What about filtering them, maybe showing only those that yet not merged to master?

- What about ordering commits, searching through them, etc.

- You ever wanted to see all the commits authored by you that are at least two months older?

- Ever needed to see commits that only include a specific set of files?

- What about tracing the evolution of a given function?

- Bisects, have you ever done those?

- You ever had a stash that you can't pop because you made changes, and now you have to resolve conflicts?

- Have you ever thought about cherry-picking a specific line from a stash, another branch, etc.?

- Ever needed to work with submodules?

- Ever thought about how nice would it be to issue a Pull request without leaving Emacs?

I'm not sure when was the last time you tried Magit, but maybe try again. Perhaps then you'd appreciate how much good stuff people built into it. It's impressive because aside from a single (hugely successful) Kickstarter campaign and some small voluntary contributions, maintainer and contributors don't get paid for the fantastic work they do, and your comment in that context sounds a bit disingenuous.

So what's the problem? Commit often, make a bunch of commits. Or commit into the same commit over and over (<c e> - extend). Then depending on level of granularity you can either group related things together, or break one big commit into a bunch of smaller ones.

Rebasing with Magit is a joy, it feels like you're a tailor and you just need to cut the fabric into nice pieces, and if sometimes things get too big or too small, you can always quickly fix it. And even when it feels that you accidentally ruined everything, you can always look at the reflog and un-ruin everything back to normal.

The custom buid system we use at $WORK can build and run tests from the index (or any git revision really) specifically to facilitate fine grained commits.

I agree: what I often want is stash of selective parts, so I can test the current stuff before commit.

Well, in Magit buffers that show diffs you can do refinements (see exact portion of changed thing in a line highlighted, not just the whole line). You can choose different diffing algorithm, ignore whitespaces, expand or narrow the context (i.e. it shows lines that changed, but you don't see the function header), detect renames, etc.

Tig is the only other tool I’ve used which comes close to the speed and capability provided by Magit. I’ve recommended it to many people who don’t want to learn Emacs for one reason or another.

It's nonlinear. With `git add -p` you can press keys to go back and forth through the hunks. If there are a lot of them then it can get tedious. With Magit, on the other hand, you see everything in a window and you can use all of your usual emacs commands to scroll/search that window, and then hit the key to stage the hunks as you desire.

So let's say you stage a few different things. Then run linter/code formatter/etc. You can see the changes done by the linter, you can refine the diff (so it shows not only the lines that changed, but also highlights the details), you can expand/narrow the context (for example if you can see the change, but can't see the function header and without it it's confusing). Then you can [selectively] stage those changes.

What about if you overwrite a few lines of something and now the original only exists in another branch? You can peek into that thing, check the diff, even jump into the version in the other branch (without having to check it out) and selectively "cherry-pick" lines of code.

It's a seamless workflow, it doesn't feel like you're doing one thing at a time, it feels more natural and doesn't require undivided focus like: "no, I can't afford a bathroom break right now, I'm in the middle of staging, goddammit."

Awww thanks, all of us who use Magit will switch back to git-gui now.

Seriously, it's not a competition of which git-client has more features.

Magit is much more than just "I can do that" thing. It is extremely efficient, it allows (probably) the most efficient git workflow that can be extended and customized.

It's not the most beautiful thing - the same thing can be said about an industrial excavator. But do you want a beauty or the efficiency? (You want beauty? download GitKraken or something) Can you imagine if someone removes all the controls inside the said excavator and replaces them with a single iPad like device in the middle of the dashboard? Yah, perhaps it'll be aesthetically pleasing, but would it be efficient, even if it has access to all the features and digging modes, etc.?

If you don't care about the efficiency of your git workflow, fine. But if you do, take my word for it, trust me - you wouldn't find a better way to deal with Git than Magit.

That's a partial hunk staging, not line-by-line based. Read the comments. IntelliJ doesn't seem to support that feature, yet (or still). I have used IntelliJ for about seven years. It does have a superb Git integration. That was the only reason why I couldn't switch to Emacs (for a very long time). I refused to believe that anyone could do better than that. I was wrong.

Pijul, Mercurial, SVN, Fossil, TFS, ... Who cares? Git has won. Either we like it or not, but we're stuck with it for a long, long time. Ping me when Github starts supporting Pijul repos. I'll send you 20 bucks or something.

You can also use `C-g` to interrupt the diffing algorithm if you just want to get to the minimal git status buffer. In fact that is the recommended way to deal with it.

Thanks but sorry, you've missed the point of my post. If you have time, please read it again. I'm pointing out that, if you think of C-c C-c in the commit buffer as being "commit", then there's an uncomfortable conclusion: magit doesn't put everything that is currently staged into the commit. Instead what magit does is freeze the contents of the commit when you open the commit message composition buffer, so anything staged subsequently doesn't make it into the commit.

(In my original message I do say i've been using magit daily for 10 years; i'm extremely familiar with all the rebasing operations you mention. i agree they're very useful and i use them multiple times a day.)