Re: Bisect limited to Merge Commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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?

hgn
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]