Re: Bisect limited to Merge Commits

From: Jacob Keller <jacob.keller@gmail.com>
Date: Apr 28, 2016, 06:44 UTC
Message-ID: <CA+P7+xq-g3JPxKROa9Ne0EGiSgSqHKgqVG3eoW9Q-dP0yPOrVA@mail.gmail.com>
In-Reply-To: <20160428061929.GA11322@virgo.localdomain>

On Wed, Apr 27, 2016 at 11:19 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

Show 26 quoted lines

> * Johannes Sixt | 2016-04-27 23:33:53 [+0200]:
>
> Hey Junio, hey Hannes,
>
>> git bisect start
>> git rev-list --first-parent --boundary origin..origin/pu |
>>   sed -ne s/-//p | xargs git bisect good
>> git bisect bad origin/pu
>>
>>and it starts bisecting among the 50-something first-parent commits between
>>origin and origin/pu.
>
> just for clarification: contributors rebase their work before pushing it on
> master. The integrator simple merges --no-ff the individual branches. Just a
> regular workflow, nothing special - except that many contributor commits will
> not build. ;(
>
> The idea is just to skip the contributor commits during bisect and focus on
> the merge commits (the ones with more than one ancestors) because they are
> likely build and testable.
>
> One possible approach is probably to sort out all non-merge commits before
> bisecting and bisect only on a this set of commits. The advantage is that the
> first bad commit is the merge commit introduced the regression. Mmmh, any
> comments?
>

I suspect doing something akin to the idea of "bisect --first-parent" would work for this use case and be more flexible in general. Your idea is pretty much what i think bisect --first-parent would do, except that it would also work for non-merge commits which happen to be in the "mainline" history.

Thanks, Jake