Hmm …

Posted Nov 9, 2018 19:52 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: Hmm … by epa
Parent article: Apache Subversion 1.11.0 released

> 'git bisect' could become aware of groups (bisecting at top-level granularity first, then optionally breaking down to the next level to find the particular sub-commit

I think this would be handled well with a `git bisect --first-parent` option which bisects the first-parent history and then starts bisecting the history between the two commits recursively on the remaining history using the same first-parent semantics. Then your "groupings" are exactly merges.

Hmm …

Posted Nov 12, 2018 4:17 UTC (Mon) by neilbrown (subscriber, #359) [Link] (2 responses)

> I think this would be handled well with a `git bisect --first-parent` option ...

What version of git do you need? Do you give "--first-parent" when you "git bisect start" or on every "git bisect good/bad"??

"revision.c" in current git contains the line

revision.c: die(_("--first-parent is incompatible with --bisect"));

which makes me wonder....

Hmm …

Posted Nov 12, 2018 8:26 UTC (Mon) by smurf (subscriber, #17840) [Link]

> which makes me wonder....

If you only do first-parent then you may end up at the point where your only possible refinement is to start bisecting a group, which you forbade git to do – after all, you used "--first-parent".

Thus, this situation requires additional code – which hasn't been implemented yet.

Hmm …

Posted Nov 12, 2018 16:24 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I'd say you just give it to `git bisect start`. Offhand, I imagine it could basically treat all non-first-parent commits as `skip`. When it finds out that it is one of the X auto-skipped commits, it unmarks the first-parent history of those candidate commits and then restarts the bisect on those commits.