Re: [PATCH] Documentation: add a planning document for the next CLI revamp

On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso [off-list ref] wrote:

In my opinion, that is a Really Bad Idea from a usability and UI
design point of view.  Each command should do one and only one thing,
and not do different things depending on what options you give it.
Git violates this rules in a number of places already, What you call
"revert-since" and "revert-in" are so different that using the same
subcommand is just going to horribly confuse users.

Better to have "git revert" print a message explining that it is
deprecated, and to tell users that they probably want either "git
cherry-pick --revert" or "git revert-file", depending on whether they
are an experienced git user (in which case they probably want git
cherry-pick --revert"), or if that person who is familiar svn or hg's
"svn revert" or "hg revert", they probably want "git revert-file".

Yeah, good points.  I guess I could just make --no-commit the default
in all cases to remove the "magic", but then it's too much typing for
the revert-in case ("eg revert --commit --in REVISION" vs. "git revert
REVISION").  Two separate commands may make more sense, but then
there's the naming issue (I had difficulty coming up with a different
name that I liked, and it appears others are having a little trouble
with the naming too).  Tough nut to crack from any angle.  :-(