git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Kevin Bracey <kevin@bracey.fi>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Jeff King <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: log --cherry and merges (was [RFC/PATCH 0/2] merge-base: add --merge-child option)
Date: Sun, 19 May 2013 13:40:59 +0100	[thread overview]
Message-ID: <20130519124059.GJ27005@serenity.lan> (raw)
In-Reply-To: <5190FC97.6020800@drmicha.warpmail.net>

On Mon, May 13, 2013 at 04:45:43PM +0200, Michael J Gruber wrote:
> Kevin Bracey venit, vidit, dixit 13.05.2013 16:26:
> > On 13/05/2013 01:22, Junio C Hamano wrote:
> >> Kevin Bracey <kevin@bracey.fi> writes:
> >>
> >>>     git log --ancestry-path --left-right E...F --not $(git merge-base
> >>> --all E F)
> >>>
> >>> which looks like we're having to repeat ourselves because it's not
> >>> paying attention...
> >> You are half wrong; "--left-right" is about "do we show the </>/=
> >> marker in the output?", so it is true that it does not make sense
> >> without "...", but the reverse is not true: A...B does not and
> >> should not imply --left-right.
> >>
> > The repetition I meant is that by the definition of ancestry-path, the 
> > above would seem to be equivalent to
> > 
> >    git log --ancestry-path --left-right E F --not $(git merge-base --all E F) $(git merge-base --all E F)
> > 
> > Anyway, revised separated-out version of the patch follows.
> > 
> > Kevin
> 
> It is certainly true that "git log --cherry" needs much less information
> than what the merge base machinery provides. I've been experimenting
> with that in order to get the speedup which is necessary for replacing
> the "git cherry" code with calls into the revision walker using "--cherry".

I think the revision machinery is the same speed as the "git cherry"
code, it's just that "git cherry" ignores merges and the cherry code in
revision.c doesn't.

Since the patch ID of a merge is just being calculated to its first
parent, I don't think it's meaningful to consider merges for "log
--cherry" but I can't quite convince myself that there's no corner case
where it is.

The following patch makes the revision cherry machinery ignore merges
unconditionally.  With it applied, there's not noticeable difference in
speed between "git cherry" and "git log --cherry".

-- >8 --
diff --git a/revision.c b/revision.c
index a67b615..19d0683 100644
--- a/revision.c
+++ b/revision.c
@@ -640,6 +640,11 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
 
 		if (flags & BOUNDARY)
 			continue;
+
+		/* Patch ID is meaningless for merges. */
+		if (commit->parents && commit->parents->next)
+			continue;
+
 		/*
 		 * If we have fewer left, left_first is set and we omit
 		 * commits on the right branch in this loop.  If we have
@@ -661,6 +666,11 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
 
 		if (flags & BOUNDARY)
 			continue;
+
+		/* Patch ID is meaningless for merges. */
+		if (commit->parents && commit->parents->next)
+			continue;
+
 		/*
 		 * If we have fewer left, left_first is set and we omit
 		 * commits on the left branch in this loop.
-- 
1.8.3.rc3.372.g721bad8

  reply	other threads:[~2013-05-19 12:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-11 12:23 [RFC/PATCH 0/2] merge-base: add --merge-child option John Keeping
2013-05-11 12:23 ` [RFC/PATCH 1/2] commit: add commit_list_contains function John Keeping
2013-05-11 12:23 ` [RFC/PATCH 2/2] merge-base: add --merge-child option John Keeping
2013-05-11 17:54 ` [RFC/PATCH 0/2] " Junio C Hamano
2013-05-11 18:48   ` John Keeping
2013-05-12 15:44 ` Kevin Bracey
2013-05-12 16:28   ` John Keeping
2013-05-12 16:33     ` John Keeping
2013-05-12 17:14       ` Kevin Bracey
2013-05-12 22:22         ` Junio C Hamano
2013-05-13 14:26           ` Kevin Bracey
2013-05-13 14:45             ` Michael J Gruber
2013-05-19 12:40               ` John Keeping [this message]
2013-05-20  6:43                 ` log --cherry and merges (was [RFC/PATCH 0/2] merge-base: add --merge-child option) Jonathan Nieder
2013-05-13 15:00             ` [PATCH 0/2] Make --ancestry-path A...B work Kevin Bracey
2013-05-13 15:00               ` [PATCH 1/2] t6019: demonstrate --ancestry-path A...B breakage Kevin Bracey
2013-05-13 15:00               ` [PATCH 2/2] revision.c: treat A...B merge bases as if manually specified Kevin Bracey
2013-05-13 16:04                 ` Junio C Hamano
2013-05-12 16:58     ` [RFC/PATCH 0/2] merge-base: add --merge-child option John Keeping
2013-05-12 17:29       ` Kevin Bracey
2013-05-13  5:02         ` Junio C Hamano
2013-05-13  7:52           ` John Keeping

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=20130519124059.GJ27005@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=kevin@bracey.fi \
    --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.
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 NNTP newsgroup(s).