On Mon, Nov 05, 2007 at 11:40:46PM +0000, Johannes Schindelin wrote:
quoted text
> Hi,
>=20
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>=20
> > Steven Grimm <koreth@midwinter.com> writes:
> >=20
> > > But that suggested command is not going to convince anyone they were
> > > wrong about git being hard to learn. I wonder if instead of saying, "I
> > > know what you meant, but I'm going to make you type a different
> > > command," we should make git revert just do what the user meant.
> > >
> > > There is already precedent for that kind of mixed-mode UI:
> > >
> > > git checkout my-branch
> > > vs.
> > > git checkout my/source/file.c
> >=20
> > That's an example of mixed-mode UI, but what you are suggesting is quit=
e=20
quoted text
> > different, isn't it?
> >=20
> > There is no other officially supported single-command-way to
> > checkout paths out of the index.
>=20
> Okay, let's step back a bit.
>=20
> We taught "git show" to show other objects than commits, by doing the=20
> obvious things.  So there _is_ a precendent to changing a commands=20
> behaviour to accept more than just commits.  And there was already anothe=
r=20
quoted text
> command for the same purpose, cat-file, which was never meant as=20
> porcelain however.
>=20
> Now, what does "revert" _mean_?  At the moment, it wants a commit, and=20
> will undo the changes that commit introduced, _and commits it_ (asking=20
> for a message).
>=20
> What would I expect "git revert -- file" to do?  It would undo the change=
s=20
quoted text
> to that file -- and since no commit was specified, I would expect it to=
=20
quoted text
> look at the changes against the index.  (IOW exactly what Steven=20
> proposed.)
>=20
> To continue the analogy, it would have to commit the undoing of the=20
> change.  But since that change never was committed, I think it is more=20
> natural to _not_ commit it.
>=20
> In the same way, I would expect "git revert <commit> -- file" to undo the=
=20
quoted text
> changes in that commit to _that_ file (something like "git merge-file=20
> file <commit>:file <commit>^:file"), but this time commit it, since it=20
> was committed at one stage.

  I agree that this is something that really makes sense to me, and does
not looks like a perversion of the UI, and quite a nice extension in
fact. And it would _finally_ solve the issue that for _ANYTHING_ on the
planet that I've used for more than 10 seconds, $SCM revert path/to/file
reverts local changes :)

  When you look at how git-revert is implemented, you'll see that it
uses the very same code as git cherry-pick does, and in fact, I've
wanted a git cherry-pick <commit> -- path1 path2 path3 for a _very_ long
time, and your proposal would just gracefully give it as a bonus I
believe (of course uncommited changes have no sense for a cherry-pick).

  I like it a lot.

--=20
=C2=B7O=C2=B7  Pierre Habouzit
=C2=B7=C2=B7O                                                madcoder@debia=
n.org
OOO                                                http://www.madism.org