From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:
Bikeshedding: If the given boundary is a tag, it could be tagging a
blob or tree rather than a commit. Would that be a scenario that
reaches this part of the code?
I do not think it is relevant.
Bisection is an operation over a "bisectable" commit DAG, where
commits can be partitioned into "new" (aka "bad") and "old" (aka
"good") camp, all descendants of a "new" commit are all "new", all
ancestors of an "old" commit are all "old". Think of the "new"-ness
as a 100% inheritable disease that happens spontaneously and without
cure. Once you are infected with "new"-ness, all your descendants
are forever "new". If you know you are free of the "new"-ness, you
know that all your ancestors are not with the "new"-ness, either.
The goal of the operation is to find a "new" commit whose parents
are all "old".
The bisectability of the commit DAG is what allows you to say "this
commit is new" to a commit somewhere in the middle of the history
and avoid having to test any descendants, as they all inherit the
"new"-ness from it (similarly when you have one commit that is
"old", you do not have to test any ancestor), thereby reducing the
number of test from N (all commits in good..bad range) to log(N).
There is no room for a tree or a blob to participate in this graph
partitioning problem. A "bad" tree that is "new" cannot infect its
children with the "new"-ness and a "good" tree cannot guarantee the
lack of "new"-ness of its parents, because a tree or a blob does not
have parent or child commits.
Thanks.
I was happy with how the bisect actually works. I was more responding the
the open question about how that piece of code may have come into existance,
and the potential thought processes that can lead to such 'mistakes'.
My line of reasoning was that it is reasonable to pass both commits and
tags, as revisions(7), to the cli as being the bad and good points in the
graph. This could then lead to a expectation that the objects they point to
should be suitably marked, which is quite reasonable for commits, and for
most tags.
However there are tags that point to the commit tree, rather than the commit
itself, so if that initial rule was followed in a simplistic manner, then
(falsely) the peeled tree of the tag would be marked as good/bad, which as
your patch identifies, would be the wrong thing to do.
The study of human error is quite interesting....
regards
Philip