git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
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 15:33:56 -0500
Message-ID: <X/9ZNM9KxZaQ2it+@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq7dogy4dx.fsf@gitster.c.googlers.com>

On Wed, Jan 13, 2021 at 12:21:30PM -0800, Junio C Hamano wrote:

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

I didn't realize --cherry-pick would work without a symmetric
difference. The documentation says:

  Omit any commit that introduces the same change as another commit on
  the “other side” when the set of commits are limited with symmetric
  difference.

And indeed, I think it silently does nothing with:

  git rev-list --cherry-pick A..B

(because there is nothing on the "other" side to match).

So you do need some symmetric difference in order to define the two
sets, but you might only want to see one of the sides.  And that is
basically what --cherry does. But having looked at the implementation of
cherry_pick_list(), it is quite happy to swap the sides internally. I
guess if we were going to make the output unsymmetric, the first thing
would be to stop doing that swap. :)

For the specifics of reverts and replays, though, I think the weirdness
has nothing to do with left/right, or showing one side. It's the
mismatched count. So if we were to make any change, it would be to keep
a count of how many times each commit appears on the other side, and
cancel them one for one.

I.e., this:

  o--M--W--M--o--
   \
    o--M--o---

might plausibly want to show "M" once on the upper branch. But:

  o--M--W--M--o--
   \
    o--M--W--M--o--

should never show M, I wouldn't think.

I'm not sure if that would be violating what existing callers expect
from "--cherry-pick", though (i.e., if it would need another name, or an
extra option to trigger).

-Peff

  reply	other threads:[~2021-01-13 20:35 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
2021-01-13 20:33                 ` Jeff King [this message]
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=X/9ZNM9KxZaQ2it+@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=arnaud.morin@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kewillf@microsoft.com \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git