git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git revert with partial commit.

From
Sergey Organov <sorganov@gmail.com>
Date
Apr 4, 2023, 19:40 UTC
Message-ID
<877curzb9u.fsf@osv.gnss.ru>
In-Reply-To
<xmqq4jpv1pcj.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> 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.

[...]
Show 5 quoted lines
> 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.

Nice, so I figure I may allow myself to still keep a weak hope for the feature, and thus stop being forbidden, even if not unreasonably, from doing something sensible. ;-)

Thanks, -- Sergey Organov

Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 18 in “git revert with partial commit.”
  1. Hongyi ZhaoApr 2, 2023
  2. Torsten BögershausenApr 2, 2023
  3. Junio C HamanoApr 3, 2023
  4. Hongyi ZhaoApr 4, 2023
  5. Phillip SusiApr 3, 2023
  6. Hongyi ZhaoApr 4, 2023
  7. Hongyi ZhaoApr 4, 2023
  8. Hongyi ZhaoApr 4, 2023
  9. Chris TorekApr 4, 2023
  10. Sergey OrganovApr 4, 2023
  11. Junio C HamanoApr 4, 2023
  12. Sergey OrganovApr 4, 2023
  13. Junio C HamanoApr 4, 2023
  14. Felipe ContrerasApr 4, 2023
  15. Sergey OrganovApr 5, 2023
  16. Felipe ContrerasApr 7, 2023
  17. Sergey OrganovApr 7, 2023
  18. Phillip SusiApr 6, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.