From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Arnaud Morin <arnaud.morin@gmail.com>,
git@vger.kernel.org, Kevin Willford <kewillf@microsoft.com>
Subject: Re: [PATCH] patch-ids: handle duplicate hashmap entries
Date: Wed, 13 Jan 2021 12:21:30 -0800 [thread overview]
Message-ID: <xmqq7dogy4dx.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <X/7ur/IcCg1AqTdZ@coredump.intra.peff.net> (Jeff King's message of "Wed, 13 Jan 2021 07:59:27 -0500")
Jeff King <peff@peff.net> writes:
> Right. There's definitely a question of whether --cherry-pick is the
> most useful thing in such a situation, but the current behavior was
> simply broken. It did not behave as advertised, and it treated one side
> of the history different from the other. So whether we want to do
> anything else to help that case, I think this at least makes
> --cherry-pick sane. :)
Yes; I think "sane" does not always equal to "useful", though ;-)
> Here are two related histories to think about.
> ...
> I suspect for most operations we care less about "remove all
> cherry-picks from both sides", but rather "give me one side, omitting
> commits that are already on the other side" (because you want to rebase
> or cherry-pick some subset).
Yes again. It means "--cherry-pick" inherently is not symmetric.
One side is the reference side (i.e. mainline), and the goal is to
remove from the other side what is in the reference side.
What we are seeing in this discussion is that "--cherry-pick" and
symmetric difference do not conceptually play well together.
But the behaviour with the patch makes the most sense when
cherry-pick is applied to a symmetric difference (provided that
doing so makes sense in the first place, that is).
next prev parent reply other threads:[~2021-01-13 20:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 16:24 rev-list with multiple commits sharing same patch-id Arnaud Morin
2021-01-11 7:59 ` Arnaud Morin
2021-01-11 9:54 ` Christian Couder
2021-01-11 18:25 ` Arnaud Morin
2021-01-12 14:17 ` Jeff King
2021-01-12 15:11 ` Jeff King
2021-01-12 15:34 ` Arnaud Morin
2021-01-12 15:52 ` [PATCH] patch-ids: handle duplicate hashmap entries Jeff King
2021-01-12 16:24 ` Arnaud Morin
2021-01-12 19:13 ` Junio C Hamano
2021-01-13 9:24 ` Arnaud Morin
2021-01-13 12:59 ` Jeff King
2021-01-13 20:21 ` Junio C Hamano [this message]
2021-01-13 20:33 ` Jeff King
2021-01-13 19:28 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7dogy4dx.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=arnaud.morin@gmail.com \
--cc=git@vger.kernel.org \
--cc=kewillf@microsoft.com \
--cc=peff@peff.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).