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

[Kevin Daudt <me@ikke.info>]

On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
> Kevin Daudt <me@ikke.info> writes:
> 
> > git log --bisect seems to do something different then git rev-list
> > --bisect
> >
> > From git-log(1):
> >
> >     Pretend as if the bad bisection ref refs/bisect/bad was listed and
> >     as if it was followed by --not and the good bisection refs
> >     refs/bisect/good-* on the command line.
> >
> > This seems to just add addition refs to the log command, which seems
> > unrelated to what rev-list --bisect does.
> >
> > So I don't see why git log --bisect --first-parent should be prohibited
> > (unless this combination doesn't make sense on itself).
> 
> Well, but think if your "unless" holds true or not yourself first
> and then say "I do not think this combination doesn't make sense",
> if you truly mean "I don't see why ... should be prohibited".
> 
> 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.

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.