All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Chris Torek <chris.torek@gmail.com>,
	Hongyi Zhao <hongyi.zhao@gmail.com>,
	Phillip Susi <phill@thesusis.net>, Git List <git@vger.kernel.org>
Subject: Re: git revert with partial commit.
Date: Tue, 04 Apr 2023 22:40:29 +0300	[thread overview]
Message-ID: <877curzb9u.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqq4jpv1pcj.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 04 Apr 2023 11:20:28 -0700")

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.

[...]

> 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

  reply	other threads:[~2023-04-04 19:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-02  9:17 git revert with partial commit Hongyi Zhao
2023-04-02 14:16 ` Torsten Bögershausen
2023-04-03 17:07   ` Junio C Hamano
2023-04-04  0:28   ` Hongyi Zhao
2023-04-03 18:29 ` Phillip Susi
2023-04-04  0:20   ` Hongyi Zhao
2023-04-04  0:37     ` Hongyi Zhao
2023-04-04 15:50       ` Hongyi Zhao
2023-04-04 16:19         ` Chris Torek
2023-04-04 17:21           ` Sergey Organov
2023-04-04 18:20             ` Junio C Hamano
2023-04-04 19:40               ` Sergey Organov [this message]
2023-04-04 19:48                 ` Junio C Hamano
2023-04-04 21:14                 ` Felipe Contreras
2023-04-05  6:39                   ` Sergey Organov
2023-04-07  0:24                     ` Felipe Contreras
2023-04-07 17:20                       ` Sergey Organov
2023-04-06 15:48     ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877curzb9u.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=chris.torek@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hongyi.zhao@gmail.com \
    --cc=phill@thesusis.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.