Re: [PATCH v4] rev-list: refuse --first-parent combined with --bisect

[Junio C Hamano <gitster@pobox.com>]

Kevin Daudt <me@ikke.info> writes:

> On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
>
>> What does such a command line _mean_?  It tells us this:
>> 
>>     Define a set by having the "bad" ref as a positive end, and
>>     having all the "good" refs as negative (uninteresting) boundary.
>> 
>> That is a way to show commits that are reachable from the bad one
>> and excluding the ones that are reachable from any of the known-good
>> commits.  The area of the graph in the current bisection that
>> contains suspect commits.
>> 
>> Now, what does it mean to pull only the first-parent chain starting
>> from the bad one in such a set in the first place?  What does the
>> resulting set of commits mean?
>
> In that case it will leave out any merged in branches.

Needs a bit more thinking (hint: branches merged into *what*?).

> I recalled reading something about this. Searching found me the GSoC
> idea:
>
>     When your project is strictly "new features are merged into trunk,
>     never the other way around", it is handy to be able to first find a
>     merge on the trunk that merged a topic to point fingers at when a
>     bug appears, instead of having to drill down to the individual
>     commit on the faulty side branch.
>
> So there is definitely a use case for --bisect --first-parent, which
> would show you those commits that would be part of the bisection.

Step back and think why "git bisect --first-parent" is sometimes
desired in the first place.

It is because in the regular bisection, you will almost always end
up on a commit that is _not_ on the first-parent chain and asked to
check that commit at a random place on a side branch in the first
place. And you mark such a commit as "bad".

The thing is, traversing from that "bad" commit that is almost
always is on a side branch, following the first-parent chain, will
not be a useful history that "leaves out any merged in branches".

When "git bisect --first-parent" feature gets implemented, "do not
use --first-parent with --bisect" limitation has to be lifted
anyway, but until then, not allowing "--first-parent --bisect" for
"rev-list" but allowing it for "log" does not buy our users much.
The output does not give us a nice "show me which merges on the
trunk may have caused the breakage to be examined with the remainder
of this bisect session".

So, yes, there is a use case for "log --bisect --first-parent", once
there is a working "bisect --first-parent", but not until then, the
command is not useful, I would think.