Re: Bisect limited to Merge Commits

[Jacob Keller <jacob.keller@gmail.com>]

On Wed, Apr 27, 2016 at 11:19 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * 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