Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:52

Junio C Hamano [off-list ref] writes:
Christian Couder [off-list ref] writes:
quoted
Le mardi 1 juillet 2008, Junio C Hamano a écrit :
quoted
Christian Couder [off-list ref] writes:
quoted
Before this patch "git bisect" doesn't really work when it is given
some good revs that are siblings of the bad rev.

For example if there is the following history:

A-B-C-D
   \E-F

and we launch "git bisect start D F" then only C and D will be
considered as possible first bad commit.
I am assuming the first bad commit in the graph is A and it is fixed by F.
Ah, I see your confusion here.  bisect is about finding regressions.
"Older ones were good, and now there is a breakage.  Who broke it?"

If F fixed it, that is already outside the bisection's scope.  The user
needs to know that by saying F is good, he is saying he knows everything
that leads to F is good.
Ok, I wasn't thinking straight.

The tricky part is that the user does not know.

Until we somehow can check B is bad, we cannot tell that the original
bisection was done incorrectly (in the sense that it was not finding
regression, but what the user could find is which commit fixed it).

If we perform a test merge between D and F and test that tree, and if that
turns out to be Ok, that would be a good indication of existence of a fix
(i.e. the topology is not "old good code was broken somewhere", but "old
broken code was fixed somewhere").  I am not sure how applicable that
approach would be in practice, though.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help