Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.

From: Pierre Habouzit <madcoder@debian.org>
Date: Nov 6, 2007, 08:49 UTC
Message-ID: <20071106084925.GC4435@artemis.corp>
In-Reply-To: <7vode8j7o5.fsf@gitster.siamese.dyndns.org>

On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:

Show 16 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> >
> >> Allowing people to revert or cherry pick partially by using paths 
> >> limiter is a very good idea; the whole "it comes from a commit so we 
> >> also commit" feels an utter nonsense, though.
> >
> > No.
> >
> > When "git revert <commit>" commits the result, "git revert <commit> -- 
> > <file>" should, too.
> 
> I was not questioning about that part.  "If 'git revert <some
> other form> foo' does not talk about commit, it should not
> commit" was what I was referring to.

  Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.

If git revert <commitish> -- path1 path2 path3 is going to work at some point, I see no harm in saying that git revert HEAD -- path1 path2 path3 work. We can also in that case spit an error message:

error: this works as a courtesy but you really meant git checkout -- path/to/file

  On some other issues I'm all about educating people and learning to
them how to "think different". But here it's a pure interface problem,
and git is the sole $scm with a revert commands that doesn't reverts
local changes wrt HEAD.

  The next release of master will have tons of UI improvements (terse
output, better options parsing, more builtins hence faster commands …),
I believe it's stopping halfway not thinking about issues like this from
a newcomer point of view.

  On the pure theoretical basis I believe you're right, it's a bit
mixing apples and oranges. On the pragmatic usability side I'm quite
sure you're wrong, because everyone is used to that:

    $ hg revert --help | head -3 | tail -1
    revert files or dirs to their states as of some revision

    $ bzr help revert | head -1
    Purpose: Revert files to a previous revision.

    $ svn help revert | head -1
    revert: Restore pristine working copy file (undo most local edits).

    $ darcs help revert | head -3 | tail -1
    Revert to the recorded version (safe the first time only).

    <put your favorite non-git scm with a revert command here>

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org