Christian Couder <christian.cou...@gmail.com> writes:
> The following part of the description:
>
> git bisect (bad|new) [<rev>]
> git bisect (good|old) [<rev>...]
>
> may be a bit confusing, as a reader may wonder if instead it should be:
>
> git bisect (bad|good) [<rev>]
> git bisect (old|new) [<rev>...]
>
> Of course the difference between "[<rev>]" and "[<rev>...]" should hint
> that there is a good reason for the way it is.
>
> But we can further clarify and complete the description by adding
> "<term-new>" and "<term-old>" to the "bad|new" and "good|old"
> alternatives.
>
> Signed-off-by: Christian Couder <chrisc...@tuxfamily.org>
> ---
> Documentation/git-bisect.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks. The patch looks good.
A related tangent.
Last night, I was trying to think if there is a fundamental reason
why "bad/new/term-new" cannot take more than one <rev>s on the newer
side of the bisection, and couldn't quite think of any before
falling asleep.
Currently we keep track of a single bisect/bad, while marking all the
revs given as good previously as bisect/good-<SHA-1>.
Because the next "bad" is typically chosen from the region of the
commit DAG that is bounded by bad and good commits, i.e. "rev-list
bisect/bad --not bisect/good-*", the current bisect/bad will always
be an ancestor of all bad commits that used to be bisect/bad, and
keeping previous bisect/bad as bisect/bad-<SHA-1> won't change the
region of the commit DAG yet to be explored.
As a reason why we need to use only a single bisect/bad, the above
description is understandable. But as a reason why we cannot have
more than one, it is tautological. It merely says "if we start from
only one and dig history to find older culprit, we need only one
bad".
I fell asleep last night without thinking further than that.
I think the answer to the question "why do we think we need a single
bisect/bad?" is "because bisection is about assuming that there is
only one commit that flips the tree state from 'old' to 'new' and
finding that single commit". That would mean that even if we had
bisect/bad-A and bisect/bad-B, e.g.
o---o---o---bad-A
/
-----Good---o---o---o
\
o---o---o---bad-B
where 'o' are all commits whose goodness is not yet known, because
bisection is valid only when we are hunting for a single commit that
flips the state from good to bad, that commit MUST be at or before
the merge base of bad-A and bad-B. So even if we allowed
$ git bisect bad bad-A bad-B
on the command line, we won't have to set bisect/bad-A and
bisect/bad-B. We only need a single bisect/bad that points at the
merge base of these two.
But what if bad-A and bad-B have more than one merge bases? We
won't know which side the badness came from.
o---o---o---bad-A
/ \ /
-----Good---o---o---o /
\ / \
o---o---o---bad-B
Being able to bisect the region of DAG bound by "^Good bad-A bad-B"
may have value in such a case. I dunno.
