Re: Bisect limited to Merge Commits

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 27, 2016, 22:25 UTC
Message-ID: <xmqqk2ji7kpr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <57213041.5070506@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 14 quoted lines

> Am 27.04.2016 um 22:56 schrieb Junio C Hamano:
>> So being able to stop at only commits on the first-parent chain is a
>> valid and useful tool.  "git bisect --first-parent" is one of the
>> things that are sometimes asked for.
>
> With origin pointing to git.git, I attempted this:
>
>  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.

That is a cute idea but I wonder if it would work well in a history full of pointless no-ff merges.

Here is a sample topology (output from "git log --oneline --graph")

    *   84ef1bb pointless
    |\  
    | * 4ae9f68 third
    |/  
    *   aec8732 pointless
    |\  
    | * fd4ed0d second
    |/  
    * 696b5c1 initial

where the tip of 'master' was initial, a side branch built 'second' on it and then 'master' made a no-ff 'pointless' merge, another side branch built 'third' on it and then 'master' again made a no-ff 'pointless' merge.

    $ git rev-list --first-parent --boundary initial..pointless

would give us 'third' and 'second' as boundaries, but by marking 'third' as GOOD, we declare to 'bisect' machinery that it and all of its ancestors are GOOD. So upon seeing 'bisect bad HEAD', we would immediately see that HEAD is the first bad commit, wouldn't we?

Actually, "pointless no-ff merges" is a red herring. Any history with side branch that branched from the first-parent chain after the commit at the bottom of the bisection range (in this example, the side branch that built 'third' was forked off of the first 'pointless' commit on the first-parent chain of 'master', which was made after the bottom of the range 'initial') would have the same problem, I would imagine.