Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]

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

Hi,

On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas
<govind@sophiasuchtig.com> wrote:
> On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@gmail.com> wrote:

> I had some very different ideas along the lines of reducing the number of
> commands (where the commands do something similar just DWIM rather
> than force me to remember or read docs on different commands), making
> commands look similar to commands from other SCMs (revert should do
> what it does for me in all the other SCMs that I have used, which is to
> checkout the HEAD copy into the working directory)

Your description of revert in various systems isn't quite accurate; it
isn't necessarily HEAD, since most systems (at least bzr and hg) can
also revert files to revisions earlier than HEAD.  In fact, questions
of how to do that have come up several times on this list, so you
wouldn't want to exclude that case.  Also, the revert behavior of git
(minus perhaps the default auto-commit) comes in pretty handy too
sometimes, and I can't easily find it in other systems (I suspect many
just drop back to diff + patch to handle the case that git provides).

I don't see why the revert command can't support all these cases that
users want (though you'd need to add flags like --since and --in to
differentiate between reverting the changes since a given commit or in
a given commit).  Doing so has the added advantage that you can
avoid/deprecate/hide/whatever the second forms of the checkout and
reset commands of git, which have long caused confusion for users in
understanding the differences between them and the revert command.

Elijah

P.S. Yes, EasyGit's revert was designed this way.  Don't look to eg
for implementation guidance, though -- I botched it, and there's a few
bugs in it due to my mistakes.  I'll be fixing it...when I get a
little bit of time.