Kevin Daudt <me@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html