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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 6, 2007, 12:25 UTC
Message-ID: <Pine.LNX.4.64.0711061216330.4362@racer.site>
In-Reply-To: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org>

Hi,

On Tue, 6 Nov 2007, Junio C Hamano wrote:

Show 15 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> 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.
> >
> > Allowing people to revert or cherry pick partially by using
> > paths limiter is a very good idea; ...
> 
> As Pierre said earlier, a partial revert via "revert <commit> --
> <paths>" and a partial cherry-pick would make quite a lot of
> sense, and in addition, it should not be too hard to add.

Yes, but Pierre also said earlier that people want to revert their local changes. And the logical thing to try that really is

	git revert <path>

Now, if you read that out in English, it does not make too much sense: "revert the path" (not "revert the _changes_ to that file"). But it is what people try to do.

However, IIUC another thing Pierre mentioned is that

	$scm revert <commit> <path>

commonly means "revert the file _to the version_ stored in <commit>". This is just different enough from "revert the _changes_ to that file stored in <commit>" to bite people, no?

> Reusing the 'merge-recursive' part should be almost trivial. The only 
> tricky part is coming up with a fake tree using base and next commit in 
> revert_or_cherry_pick() for this purpose.

FWIW I really wanted to use the merge-file machinery, not the merge-recursive one. But since "<path>" can be a directory, too, I was mistaken, and you are correct, as always.

Show 5 quoted lines

> As to "reverting to the index" case, if somebody is interested in doing 
> a builtin-checkout.c, please keep in mind that major parts of that work 
> should be made available to the implementation of "git revert [--] 
> <paths>", as it appears that it will be exactly the same as "git 
> checkout" with the same set of options.

I was planning to put cmd_checkout() into builtin-reset.c for that reason.

But first things first, that "git remote prune" with --mirror'ed repositories misbehaviour annoys me just enough that I started converting this script first. It has been stable enough for quite a long time, and the script now shows its limitations.

Besides, remote.[ch] makes it easy, even if not _really_ easy.

Ciao, Dscho