On Wed, Nov 22, 2017 at 05:01:29PM +0000, Adam Dinwoodie wrote:
> > So if you test a commit that git bisect asks you to test, and it
> > appears that this commit is "new", then you can just discard the
> > previous "new" commit because it will give you less information than
> > the new "new" one.
> > (The old "new" will not let you discard any commits that the new "new"
> > commit allows you to discard, because it is a descendant of the new
> > "new" commit.)
> >
> > If you don't test the commit that git bisect asks you to test, then
> > git bisect assumes that you know better and discards the old "new".
>
> Ah, that makes sense, thank you for the explanation.
>
> In my case, I knew two commits were "new", but didn't know which would
> provide more information to the bisect algorithm; I'd assumed if I
> provided both, Git would work out the appropriate thing to do with the
> combined information without me needing to work it out.
Yeah, I really would have expected this to work, too. Should we be
taking the merge base of the set of "new" commits, and using that as the
true "new"?
I.e., with this graph:
A--B--C--D
\
E--F
if I mark D and F as bad, can we assume that B, C, and E are "new", too,
and treat "B" as the new single "new"? That breaks down if the bug was
introduced independently on each branch, but I think bisect explicitly
doesn't handle such a case.
What might give it trouble is if there are multiple merge bases, like:
G--H-----
/ \ \
A--B--C--D \
\ \
E--------F
The flip to "new" could have been on the G-H branch, or in B.
So maybe that's not workable.
(I've never really dug into the bisect algorithm, and this is written
largely off the cuff, so I'm fine if the response is "nope, you have no
idea what you are talking about").
-Peff
