> The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are b

> The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user. The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.