Junio C Hamano <gitster@pobox.com> writes:

quoted text
> 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.

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.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html