On Fri, Jan 13, 2017 at 8:14 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
I agree that there could be improvements in this area. Though from my experience with special cases, like when a good commit is not an ancestor of the bad commit (where there are probably bugs still lurking), I think it could be tricky to implement correctly in all cases, and it could make it even more difficult, than it sometimes already is, to explain the resulting behavior to users.
