Sergey Organov <sorganov@xxxxxxxxx> 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).
