[jlgreco]

You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake.

If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful) 'git reset --hard/--soft <commit>', or you would have a situation where you have to use 'uncommit' to (for example) re-commit something, or you would be left with a git-uncommit command and still have git-reset for related operations. Why would any of that be better?

You could split the third invocation of git-reset off into its own command, but honestly I don't see the utility in doing that.

[ams6110]

Disagree. A git-uncommit command tells you by its name what it's going to do, even if you know nothing about git or even if you don't know what a commit is, you can assume that git-uncommit will undo it.

git reset --hard tells you absolutely nothing obvious about what it's going to do unless you understand git and its specific incantations. You have to learn git commands, rather than intuit them.