Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
On Mon, Nov 05, 2007 at 11:40:46PM +0000, Johannes Schindelin wrote:
Show 48 quoted lines
> Hi,
>
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
> > Steven Grimm <koreth@midwinter.com> writes:
> >
> > > 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
> >
> > That's an example of mixed-mode UI, but what you are suggesting is quite
> > different, isn't it?
> >
> > There is no other officially supported single-command-way to
> > checkout paths out of the index.
>
> Okay, let's step back a bit.
>
> We taught "git show" to show other objects than commits, by doing the
> obvious things. So there _is_ a precendent to changing a commands
> behaviour to accept more than just commits. And there was already another
> command for the same purpose, cat-file, which was never meant as
> porcelain however.
>
> Now, what does "revert" _mean_? At the moment, it wants a commit, and
> will undo the changes that commit introduced, _and commits it_ (asking
> for a message).
>
> What would I expect "git revert -- file" to do? It would undo the changes
> to that file -- and since no commit was specified, I would expect it to
> look at the changes against the index. (IOW exactly what Steven
> proposed.)
>
> To continue the analogy, it would have to commit the undoing of the
> change. But since that change never was committed, I think it is more
> natural to _not_ commit it.
>
> In the same way, I would expect "git revert <commit> -- file" to undo the
> changes in that commit to _that_ file (something like "git merge-file
> file <commit>:file <commit>^:file"), but this time commit it, since it
> 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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>