From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 20 May 2013 06:43:43 GMT
Subject: Re: log --cherry and merges (was [RFC/PATCH 0/2] merge-base: add --merge-child option)
Message-ID: <20130520064343.GC2919@elie.Belkin>
In-Reply-To: <20130519124059.GJ27005@serenity.lan>

John Keeping wrote:

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

I guess merges should be skipped in the left-vs-right tally earlier,
too?

		if (flags & BOUNDARY)
			;
		else if (commit->parents && commit->parents->next)
			;
		else if (flags & SYMMETRIC_LEFT)
			left_count++;
		else
			right_count++;

With that tweak (or without it --- a sloppy count is fine), this
patch makes sense to me.  I guess some tests would be useful to
demonstrate that --cherry doesn't notice duplicate first-parent
diffs in merges.

Thanks,
Jonathan