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

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