I’m on macOS and using the Edit → Text → Revert Modification command (⌘K, ⌘Z) on a modification with only whitespace and the command does nothing. Is this a bug?
Another possible bug is that when I click on the red line showing the previous content, it just turns black and the cursor disappears:
After some more testing it turns out that many other modifications also do not revert, not only whitespace changes. There’s no output in the console when this fails.
The revert functionality seems to be sensitive to things like the selection and/or cursor location in relation to the diff hunks when it comes to doing a revert, particularly in cases where there are multiple changes on a line and the like.
Something to try would be to use the navigation commands (Goto > Next Modification for example) to move the cursor and selection to the thing you want to revert and then try the revert to see if that works better.
This is correct, the revert functionality reverts a single modification, not a hunk of modifications. The inline-diff only shows hunks.
Okay, that makes a bit more… sense. Not exactly usable, but at least logical. Personally, I think a Revert Hunk command would be much more useful in most of my daily cases (although being able to revert each single modification in a hunk is cool too).
@OdatNurd Yeah, skipping between modifications works. It’s still a pain to revert a whole hunk with many modifications, but it’s possible at least.
One last feedback and strong argument for implement the Revert Hunk command:
In my opinion the current functionality is pretty much “useless”. If I comment out 10 lines of code, and want to revert back to the original version, I have to go to every line and find exactly the position of the comment characters with the cursor and then and only then does the key command work.
I appreciate the possibility of going inside a hunk and being able to manipulate each individual change, but considering how most people use Git (e.g. by calling git add --patch), that usage is almost always based on hunks.
As outlined in the post below, it seems like the revert functionality reverts everything that’s covered by the selection in the file. In that case using the Goto functionality to jump to the change works because it sets the selection to just that change.
So in that regard, you should be able to revert a hunk currently by manually spanning it with a selection. Note however that regardless of this, if the git_diff_target is set to index (which it is by default) you can’t revert changes that are already staged because as far as the incremental diff is concerned there isn’t any diff hunk there at all.
