Shuang He [off-list ref] writes:
If A is bad commit, and C fixed it, and then F is bad again,
A -> B -> C -> D -> E -> F -> G -> H (master)
\ \ /
a -> b... c -> d -> e->f (feature 1)
Start with H as bad commit, and D as good commit, it's possible git-bisect would jump to c, and it will lead to wrong direction
If bad-branch-first is used, it would be:
1. first round found F
2. end
It is unclear from the way you drew the picture if "F" is supposed to be a
merge of "E" and "f", but I'd assume that it is.
So what you are saying in 1. is "skip from H until you hit a first merge
(without testing any intermediate commit), find F and stop to check it,
and find that it is broken".
What makes you decide "2. end"? The fact that both of its parents "E" and
"f" are Ok? IOW, it won't be "2. end" if one of the parents of the merge
is broken?
What if there is _no_ merge from a side branch but there were breakages in
A (fixed in C) and then F in your original picture, i.e.
A---B---C---D---E---F---G---H (broken)
x o x
and you are hunting for the bug starting from H? How does your algorithm
help? I grossed over the linear part by saying "skip from H until you hit
a first merge", but in general, what is your plan to handle linear part of
the history?
A totally unacceptable answer is "It does not help linear case, but it
helps when there are merges". The a-thru-f side branch in your picture,
or any "culprit side branch that was merged" your algorithm finds in
general, would eventually have a linear segment, and having x-o-x in the
history fundmentally breaks "bisect"---your band-aid will not help.
The whole idea behind using "bisect" to gain efficiency in isolating the
issue depends on "Once you see a Good commit, you do not have to search
beyond its ancestors", as it is to look for a single breakage that
persists to the "Bad" commit you give, and as far as "bisect" is
concerned, the breakage at A in your example is an unrelated breakage that
did not persist through the history to the "Bad" commit H.
On 2011/1/25 4:04, Junio C Hamano wrote:
Shuang He[off-list ref] writes:
quoted
If A is bad commit, and C fixed it, and then F is bad again,
A -> B -> C -> D -> E -> F -> G -> H (master)
\ \ /
a -> b... c -> d -> e->f (feature 1)
Start with H as bad commit, and D as good commit, it's possible git-bisect would jump to c, and it will lead to wrong direction
If bad-branch-first is used, it would be:
1. first round found F
2. end
It is unclear from the way you drew the picture if "F" is supposed to be a
merge of "E" and "f", but I'd assume that it is.
Oh, I lost this mail
That graph is different from what I meant, when shown in different email
client.
It's G which is merged from e and F
So what you are saying in 1. is "skip from H until you hit a first merge
(without testing any intermediate commit), find F and stop to check it,
and find that it is broken".
What makes you decide "2. end"? The fact that both of its parents "E" and
"f" are Ok? IOW, it won't be "2. end" if one of the parents of the merge
is broken?
I think the correction above should have answer those two questions.
What if there is _no_ merge from a side branch but there were breakages in
A (fixed in C) and then F in your original picture, i.e.
A---B---C---D---E---F---G---H (broken)
x o x
and you are hunting for the bug starting from H? How does your algorithm
help? I grossed over the linear part by saying "skip from H until you hit
a first merge", but in general, what is your plan to handle linear part of
the history?
If the history is linear, the new algorithm won't help, it will just
behavior like default git-bisect algorithm.
A totally unacceptable answer is "It does not help linear case, but it
helps when there are merges". The a-thru-f side branch in your picture,
or any "culprit side branch that was merged" your algorithm finds in
general, would eventually have a linear segment, and having x-o-x in the
history fundmentally breaks "bisect"---your band-aid will not help.
The whole idea behind using "bisect" to gain efficiency in isolating the
issue depends on "Once you see a Good commit, you do not have to search
beyond its ancestors", as it is to look for a single breakage that
persists to the "Bad" commit you give, and as far as "bisect" is
concerned, the breakage at A in your example is an unrelated breakage that
did not persist through the history to the "Bad" commit H.
In the example above (after we know G is merged from e and F),
Those commits are old bad commit: A, B, a, b, ..., c, d (but we don't
care about those old bad commits, we cared about latest bad commit that
we met which is F)
It's possible that default git-bisect would jump to these old bad
commits, and will finally find an old first bad commit
With bad-branch-first, it could help us to get away from the trouble
that old culprit commit exist on feature1 branch for a period of time
not fixed
Thanks
--Shuang