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

> 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.