Don't miss "Staging parts of a hunk", which is Magit's killer feature, IMO. You can easily go through your current diff (from staged) and add/remove single lines from the staged delta.
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.
https://github.com/caldwell/commit-patch
Works on generic diff buffers, and is not tied to git specifically. And you can just edit the diff buffer, which gives you infinite flexibility. Since emacs already has vc mode, the only extra thing magit does is rebasing. For everything else, vc-mode and commit-patch are superior.
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/
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.
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.
For the rest of us we can select lines in vscode, and then either:
- right click,
- ctrl+shift+p <type stage, stage selected lines>
- u for hunks
- 1 for individual lines
`git` (the binary) respects your choice of editor, as indicated by the environment variable `EDITOR`.
You should be able to do something like `EDITOR=code git add -p`, it'll open up hunks for editing in `code` (or intellij, or textedit, or whatever).
I'm sure magit is nice. It's just that everything you list as nice things about magit are in vanilla git as well. Maybe you prefer the presentation in magit, that's fine. The point is to be fully aware of the available options - which the author of the article doesn't seem to be, as they only compare against git add -p, not against git gui.
The one thing that's truly missing in vanilla git as far as I know is the ability to edit the index directly, without editing the checked out files. (Does magit allow that? It's not an advertised feature in the article as far as I can see...)
Magit is not trying to replace Git, it's not pretending to be something else. You still have pretty much everything what's in Git. You can still use your aliases and run vanilla git commands. So why do you need Magit? For efficiency. You don't care about your efficiency? Fine. But please don't make conclusions that the advocates of Magit don't know better. We have tried other alternatives and we have used git command line.
> ability to edit the index directly, without editing the checked out files
What? I don't think I understand what you're asking for here. You stage parts of a file or the whole file. It shows up in "Staged changes" section of Magit buffer. You edit the file, save it, parts that are diverse now will be shown within "Unstaged changes" in a nice diff. You may choose to stage new changes, you may resolve conflicts in a three-way-merge window, discard your changes (staged changes remain), etc.
Why would you want to edit staged parts without modifying the file itself? I don't get it.
The common pattern is that as a consequence of squashing, rebasing, and so on, an early patch in the series has a bug / compile error that is trivially fixed in the next patch in the series.
In those situation, you have to fix the first commit in a middle of a rebase, but keep the result _after_ the next patch the same. This can currently be done by making the change, immediately reverting it, and then squashing things together again. That is, before you have:
o -- A -- B
o -- A -- F -- F^{-1} -- B
o -- A' -- B'
---
You don't have to know Emacs to use Magit. People often try Magit, usually because someone shows them the workflow. They don't even want to learn Emacs to begin with, but Magit looks awesome.
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."
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.
Remember how Windows "won" ?
I won't ever use Github now (how are you going to export all those non-git features like tickets when github is not desirable anymore, hmm?), and neither should you if you care even a tiny bit about open source software !
JSON wasn't a very well-thought idea, we tried to "fix" it with yaml (which turned out to be even worse), compare it with EDN (which is far better, but sadly nobody outside of Clojure community uses much)
> Remember how Windows "won"
Windows still dominates desktop OS market and we're still waiting for "Year of Linux on the desktop". Every year some people claim it to be "this is it", but in reality, it is still far from becoming reality. With WSL now even long-time Linux users are tempted to go back to Windows. And honestly I personally don't like that.
My point is - "worse is always better" *
As I said: either you like it or not - we're stuck with Git and now with Github too.
---