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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2015, 20:13 UTC
Message-ID: <xmqqsidb5m2r.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150311184512.GB5442@vps892.directvps.nl>

Kevin Daudt <me@ikke.info> writes:

Show 17 quoted lines

> 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*?).

Show 11 quoted lines

> 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.