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...)
> nice things about magit are in vanilla git as well
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.
It happens to me with some regularity while massaging large patch series via rebase.
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
Then:
o -- A -- F -- F^{-1} -- B
Then you squash A and F and F^{-1} and B to get:
o -- A' -- B'
Having a more convenient way of doing such fixups would be nice, and I think being able to edit the index directly would help in some of them.
With Magit I wouldn't even need to do that. I would just snapshot the file * and continue changing it, then when I need the original version of it I would just pop it out off the stash.
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...)