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

Junio C Hamano [off-list ref] writes:

Johannes Schindelin [off-list ref] writes:

quoted

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.

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.

When replaying the change from A->B (when cherry-picking, A is
the parent and B is what was named from the command line; when
reverting, they are the other way around), instead of doing the
three-way merge using:

	merge-recursive A HEAD B

you would first come up with a modified tree B' that has the
identical contents to A _except_ the parts the path limiters
specify which are taken from B.  Then running

	merge-recursive A HEAD B'

would replay the revert or cherry-pick of change from A->B,
limited by the path, on top of the current HEAD.

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 am wondering what "git cherry-pick -- <paths>" should do.  My
current thinking is that it would not make any sense at all.