On Sat, Nov 01, 2008 at 02:27:03PM -0600, Elijah Newren wrote:
>
> There is another option, though it has its own problems too. There
> are basically two kinds of reverting here -- reverting all the changes
> *in* a given revision (which I'll called 'revert-in') and reverting
> all the changes *since* a given revision (typically HEAD; I'll call
> this 'revert-since'). These two operations can be supported from the
> same command, though their use cases are different enough that it may
> seem slightly weird:
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".
- Ted
--
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
