Re: Bisect limited to Merge Commits

On Wed, Apr 27, 2016 at 11:19 PM, Hagen Paul Pfeifer [off-list ref] wrote:

* Johannes Sixt | 2016-04-27 23:33:53 [+0200]:

Hey Junio, hey Hannes,

quoted

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