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 <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... Yes, sorry, the `HEAD` in my sentence was spurious. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpz5tGx0l9ry.pgp
Description: PGP signature
