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

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

tisdag 06 november 2007 skrev Johannes Schindelin:
> Hi,
> 
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
> 
> > 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 think that _if_ we allow "git revert <path>" to mean "revert the 
> changes to <path>, relative to the index" (which would be the same as "git 
> checkout <path>"), then committing that change just does not make sense.
> 
> And it is this behaviour that people are seeking, not "git revert <commit> 
> <path>".

I'm not convince making every command perform enitrely all kinds of actions 
just because other SCMs interpret a name differently. git revert today 
creates a *new* commit. Keep it simple. I think its ok that it mentions 
another comnand when it detects arguments that does not make sense. There is 
no right or wrong with interepreting reset either way, but not both ways 
please. The confusion with checkout and reset is enough.

-- robin