Re: Bisect limited to Merge Commits
- From
- Hagen Paul Pfeifer <hagen@jauu.net>
- Date
- Apr 28, 2016, 06:19 UTC
- Message-ID
- <20160428061929.GA11322@virgo.localdomain>
- In-Reply-To
- <57213041.5070506@kdbg.org>
* Johannes Sixt | 2016-04-27 23:33:53 [+0200]:
Hey Junio, hey Hannes,
Show 7 quoted lines
> 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