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

On Tue, Nov 06, 2007 at 09:06:56PM +0100, Robin Rosenberg wrote:

tisdag 06 november 2007 skrev Johannes Schindelin:

quoted

Hi,

On Mon, 5 Nov 2007, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Mon, 5 Nov 2007, Junio C Hamano wrote:

quoted

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.

Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.

Mike