I think it looks similar. But if I'm reading that thread correctly then there was never a patch created, right?
On Thu, Apr 12, 2018 at 1:33 AM, Stefan Beller <sbel...@google.com> wrote: > On Wed, Apr 11, 2018 at 3:55 PM, Harald Nordgren > <haraldnordg...@gmail.com> wrote: >> When ran with '--merges-only', git bisect will only look at merge commits -- >> commits with 2 or more parents or the initial commit. > > There has been quite some talk on the mailing list, e.g. > https://public-inbox.org/git/20160427204551.GB4613@virgo.localdomain/ > which suggests a --first-parent mode instead. For certain histories > these are the same, > but merges-only is more restrictive for back-and-forth-cross merges. > > > >> >> Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com> >> --- >> >> Notes: >> Proof of concept of a feature that I have wanted in Git for a while. In >> my daily work my company uses GitHub, which creates lots of merge commits. >> In general, tests are only ran on the tip of a branch before merging, so the >> different commits within a merge commit are allowed not to be buildable. >> Therefore 'git bisect' often doesn't work since it will give lots of false >> positives for anything that is not a merge commit. If we could have a >> feature to only bisect merge commits then it would be easier to pinpoint >> which merge causes any particular issue. After that, a bisect could be done >> within the merge to pinpoint futher. As a follow-up to this patch -- we >> could potentially create a feature that automatically continues into regular >> bisect within the bad merge commit after completed '--merges-only' bisection. > > The github workflow you mention sounds as if --first-parent would do, too?
