Re: git revert with partial commit.

> On Tue, Apr 4, 2023 at 3:08 PM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > 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.
>>
>> If I got this right, you believe that "git merge" should never have
>> support for "partial merges", whereas it makes sense for cherry-pick and
>> revert? If so, I disagree. There is no reason for Git to strictly
>> prevent me from using the feature specifically in "git merge" (once it's
>> otherwise implemented), provided I do mean it and didn't do it by
>> mistake.
>>
>> Please notice that I can do it right now already (and I did a few
>> times), only with a more pain than necessary, and I don't see why this
>> pain is to be preserved (provided we do have the feature implemented in
>> the future). Besides, "git merge" is only a helper, and it'd be an
>> improvement if it'll be capable to help in more cases.
>
> This sounds awfully familiar to Mercurial's reluctance to support
> rewriting history. It wasn't the tool's place to prescribe what the
> users should or shouldn't do.
>
> If the user wants to do it, the tool should help him do it, not
> pontificate about what is heretic.
>
> The user is still going to do it, like with a rebase plugin on
> Mercurial, or with `git filter-branch` and then merge the result. All
> the tool is achieving is being annoying by not helping the user.