I just upgraded to magit 2.1.0. (And also to emacs 25.0.50 and git 2.3.1.)
Previously, in the *magit*
buffer I could:
- Select a hunk in the Unstaged area.
- Type v and answer yes to reverse it.
This was handy.
But now in magit 2.1.0 it gives an error: "Cannot reverse unstaged changes"
.
Why?
Taking a hint from the error message, I discovered I can still do this, albeit in a somewhat "backwards" way with more steps:
- stage the hunk. (Feels backwards; moving it closer to committed state.)
- Nav down and select it in the Staged area.
- Press v, answer yes.
- However the hunk is still Staged, so finally I have to unstage the hunk.
Is this a bug, or, is it intentional and/or I'm being dense? If the latter, can you help me understand?
UPDATE: After thoroughly RTFinfo-ing, I see that there are two commands:
- v
magit-reverse
Reverse the change at point in the working tree. - k
magit-discard
Remove the change at point from the working tree.
It seems that k magit-discard
does what I was used to v doing before. It does work on an unstaged hunk.
So practically I just need to retrain my muscle memory to use k. I could post that as a self-answer. But I guess I'm still curious about the rationale, because I imagine understanding it will help me understand magit better overall.
k
discards anuncommitted change in earlier versions of magit as well, and seems the appropriate command for what you're doing.v
is for git revert: creating a new commit that makes the opposite change of a prior one. I guess reverting a change that hasn't actually been committed is the same as discarding it, but 'revert' has specific meaning as a git command.v
was bound tomagit-revert-item
(the "reverse" terminology comes from there, @PythonNut) and for unstaged items this used to do amagit-discard-item
(as also bound tok
) -- see line 4872 here. Apparently I accidentally learned that special meaning ofv
, which worked, when I ought to have learned to usek
.