Re: [PATCH] patch-ids: handle duplicate hashmap entries

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2021, 20:21 UTC
Message-ID: <xmqq7dogy4dx.fsf@gitster.c.googlers.com>
In-Reply-To: <X/7ur/IcCg1AqTdZ@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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 ;-)

Show 6 quoted lines

> 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).