From: Kevin Bracey <kevin@bracey.fi>
Date: Sun, 12 May 2013 17:29:38 GMT
Subject: Re: [RFC/PATCH 0/2] merge-base: add --merge-child option
Message-ID: <518FD182.5020606@bracey.fi>
In-Reply-To: <20130512165829.GM2299@serenity.lan>

On 12/05/2013 19:58, John Keeping wrote:
>
> With the patch below, the --ancestry-path version drops to under 2
> seconds.
>
> I'm not sure if this is a good idea though.  It helps me say "I know
> nothing that isn't on the ancestry path can be patch-identical, so don't
> bother checking if it is" but it regresses users who want the full
> cherry-pick check while only limiting the output.

Hmm. Should an excluded commit be a valid comparator? Is it 
sensible/correct to show a left commit as "=" to a right commit that has 
been excluded by the revision specifiers? Doesn't sound right to me.

I'm not convinced that there's a valid use-case that you're regressing 
here. If --ancestry-path is being misused (the user's assertion that 
non-ancestry doesn't matter is wrong) the "error" of not noting culled 
patch-identical commits is nothing compared to the fact we're already 
totally omitting the non-identical ones.

Kevin