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

On Tue, Nov 06, 2007 at 09:29:42AM +0000, Mike Hommey wrote:

On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit [off-list ref] wrote:

quoted

On Tue, Nov 06, 2007 at 04:54:02AM +0000, 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 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:

It seems to me git revert HEAD -- path1 path2 path3 should revert the changes
made in the commit pointed to by HEAD, not revert the changes in the working
tree or the index...

  Yes, sorry, the `HEAD` in my sentence was spurious.

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