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

["Elijah Newren" <newren@gmail.com>]

On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso <tytso@mit.edu> 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.  :-(