Re: git revert with partial commit.

[Junio C Hamano <gitster@pobox.com>]

Sergey Organov <sorganov@gmail.com> writes:

>> This kind of operation produces a new commit, so there's no such
>> thing as a partial revert or partial cherry-pick, at least in
>> terms of "things Git can do by itself".  But we, as humans writing
>> programs, wish to *achieve* such things.
>
> So, why Git can't help us achieving it by supporting paths limiting in
> (all) merge operations? There seems to be no absolute obstacles, just a
> luck of support.

I think there is no fundamental reason to forbid an optional
pathspec to "cherry-pick" and "revert", given that a commit that
results from either "git cherry-pick" or "git revert" is called a
"cherry-pick" or a "revert" merely by convention and there is no
tool-level support to treat them any specially at merge or rebase
time [*1*].  It would make it harder to design tool-level support
for full cherry-picks or reverts, but that is a problem for future
generation, not ours ;-)  Allowing pathspec to "merge" and recording
the result as a merge of two (or more) parents is an absolute no-no
but that is not what we are discussing.

But in practice, the part that takes the most brain work in a revert
or cherry-pick that is not an outright "the effect of that commit as
its entirety is now gone" is not the mechanical (partial)
reapplication, but coming up with a good split of the original (or
the reverse of the original) and a good explanation.  Especially
given that it would be just the matter of running these commands
with "--no-commit", selectively resetting the paths that the user
does not want to touch, before spending some quality time describing
what the user did in the resulting commit, it is very understandable
if teaching pathspec to these commands has been outside anybody's
priority list so far.

But I do not think Chris meant to say "you should not expect such a
feature"; what we heard was a reasonable explanation of how the
current world works, and I do not see a reason to react strongly to
such a statement as if you were unreasonably forbidden from doing
something sensible.


[Footnote]

*1* If there were, it would totally be a different story.  For
example, merging a branch that has a revert of a commit X to a
branch that has the original commit X _may_ want to avoid replaying
the revert from the side branch in the result depending on the
circumstances, but it will be even less clear what to do if such a
"special cased" revert were a partial one).