- git revert {rev} to nuke changes and go back to how the world was
- git uncommit to return to the state literally before git commit
- git unstage to unstage a file
The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations...
So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and should come with an interactive confirmation prompt and other safety and hygiene messages.
> git uncommit to return to the state literally before git commit
This is ambiguous because there are many such states.
1. Clean working tree, before you began hacking on the code.
2. Modified working tree.
3.1. Modified working tree with staged changes.
3.2. Clean working tree with staged changes.
It's impossible to know which state you want to go back to without telling git. That's what hard, mixed and soft resets do: they bring you back to states 1, 2 and 3.2, respectively.
The default is a mixed reset. I suppose state 2 is what most people want when they try to undo a git commit. So it already does the right thing by default, no?
The only remaining problem is the git reset argument. An undo command will always reset to the previous commit, there should be no need for arguments. Stuff like HEAD^ or HEAD~1 is quite obscure to the uninitiated. We could certainly have a git undo command that runs git reset HEAD^ and allows hard and soft resets. Not sure why it doesn't already exist. Has anyone ever attempted to get that merged into mainline git?
- git revert {rev} to nuke changes and go back to how the world was
- git uncommit to return to the state literally before git commit
- git unstage to unstage a file
The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations...
So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and should come with an interactive confirmation prompt and other safety and hygiene messages.