On Wed, Apr 27, 2016 at 11:19 PM, Hagen Paul Pfeifer <hagen@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html