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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit <madcoder@xxxxxxxxxx> wrote:
> On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 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...

Mike
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux