On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso <tytso@xxxxxxx> 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. :-(
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
