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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 10, 2015, 23:12 UTC
Message-ID: <xmqqoao0xx9p.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150310225509.GA5442@vps892.directvps.nl>

Kevin Daudt <me@ikke.info> writes:

Show 14 quoted lines

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