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

From: Pierre Habouzit <[email-masked]>
Date: Tue, 06 Nov 2007 13:48:33 +0100

On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>
> > Junio C Hamano <[email-masked]> writes:
> >
> > > Johannes Schindelin <[email-masked]> writes:
> > >
> > >> In the same way, I would expect "git revert <commit> -- file" to undo the
> > >> changes in that commit to _that_ file (something like "git merge-file
> > >> file <commit>:file <commit>^:file"), but this time commit it, since it
> > >> was committed at one stage.
> > >
> > > Allowing people to revert or cherry pick partially by using
> > > paths limiter is a very good idea; ...
> >
> > As Pierre said earlier, a partial revert via "revert <commit> --
> > <paths>" and a partial cherry-pick would make quite a lot of
> > sense, and in addition, it should not be too hard to add.
>
> Yes, but Pierre also said earlier that people want to revert their local
> changes.  And the logical thing to try that really is
>
> 	git revert <path>
>
> Now, if you read that out in English, it does not make too much sense:
> "revert the path" (not "revert the _changes_ to that file").  But it is
> what people try to do.
>
> However, IIUC another thing Pierre mentioned is that
>
> 	$scm revert <commit> <path>
>
> commonly means "revert the file _to the version_ stored in <commit>".
> This is just different enough from "revert the _changes_ to that file
> stored in <commit>" to bite people, no?

  Yeah but that's what checkout is for. The main source of iritation for
new users comes (IMHO) from svn, where `svn revert path/to/file` is part
of the workflow: in case of a conflict when you `svn up`, you have
either to:
  (1) fix the conflict and `svn resolved path/to/file`
  (2) drop your changes and take the trunk version `svn revert path/to/file`

People really expect git revert -- path/to/file to do the same as git
checkout HEAD -- path/to/file. Though I believe that like I said, maybe
we don't wan't git revert -- path/to/file to become the first class
command to do that, but rather to do what the user meant, hinting him in
the direction of the proper command. I wasn't really advocating that
git-revert should be a complete implementation of what git checkout
<comitish> -- <paths> does. YMMV.

--
·O·  Pierre Habouzit
··O                                                [email-masked]
OOO                                                http://www.madism.org