On 03/28/2011 08:57 PM, demerphq wrote: > On 28 March 2011 20:23, Matthieu Moy<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> Andrew Garber<andrew@xxxxxxxxxxxxxxxx> writes: >> >>> On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy >>> <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >>> >>>> Then which commit do you specify as "good"? >>> >>> Any ancestral commit *on the same branch* which is know to be working. >> >> What is the point is finding manually a commit *on the same branch* when >> the tool can do that for you? You don't know how old the breakage is, so >> finding the first good commit will take some time. Knowing that the >> other branch is good gives you a hint that the common ancestor between >> branches should be good, so a good start would be to find the common >> ancestor. > > This doesn't make a lot of sense to me. It is just as likely NOT to be useful. > > It could just as easily have been fixed in the other branch. So > knowing its good wont tell you where it was broken. > > This started off with: > > o--o--o--B > / > --o--o--o--o--G > > So lets say that the reality of each node looks like this: > > B--B--B--B* > / > --B--B--B--G--G* > > How does knowing that G* is good help us find what broke B* again? > Because if G* is good and B* is bad, git-bisect knows to look for the merge-base (the leftmost lower B in your graph) to know that it's not looking at uninteresting commits. > Your description matches the case of something like this: > > B--B--B--B* > / > --G--G--G--G--G* > > But what about something like this: > > Bx--B--B--B* > / > --Gz--By--B--Gx--G* > > How does knowing that G* is good help you to find that Bx broke the > code in the B* branch again? > Because it helps locate Gz as the common ancestor between G* and B*. To bisect a problem with B*, you'd mark B* as bad and, assuming Gz is a stable release from which the feature-branch B has arisen, you'd mark Gz as good. Then bisect will quite quickly find that Bx is the culprit. Or, if G* works well but B* does not and you can't be arsed to locate the common ancestor yourself, you mark G* as good and B* as bad and then git-bisect will automatically reset the "good" mark from G* to Gz. This ofcourse doesn't work when the two points in doesn't share a common ancestor, although that should be a rare occasion indeed and won't make much sense. > Presumably 'By' broke the G* branch which was then fixed by Gx and > none of this information helps you at all identify that Bx broke the > B* branch. > You're right. For that, you'd need two different bisects. If the two breakages are identical (an unlikely situation, but still), you'd end up with git-bisect finding a single commit when marking GB* (the merge of G* and B*) as bad and Gz as good. Which one is hard to tell though. But then again, git-bisect has never claimed to be able to locate all bugs at once. It can just help you locate where a particular bug was introduced. There are some cases where it will fail quite gruesomely though. When one bug is covered by another and fixing the first bug uncovers the one you're bisecting for. Even then it will still cut down considerably on time spent doing implemetation analysis (aka "staring at code"). > Whereas a plain binary search on the B* branch would eventually find > that Bx was responsible. > True, but a binary search would mean about a bazillion git-bisect runs on large and complex history (such as the kernel, or git itself) when the bug is located in an already merged feature-branch, but noone knows which one. >>> Perhaps you could give a concrete example of where you could use it >>> for multiple branches simultaneously? >> >> Well, see my previous email. > > Where you said "It's not uncommon in real life to face the "it works > in branch foo but > not in branch bar, where did it break?" problem. And one expects a great > tool such as Git to be able to answer it." > > Seems to me that this is trying to cram two questions into one: > > A) where did branch foo diverge from branch bar and > B) which commit between that ancestor and bar did things break. > The only question git-bisect tries to answer is "which is the first bad commit". If you want the implementation details, I suggest you read the code, but naturally it knows how to walk the DAG it's inspecting and naturally it tries to make life easier for the human it inevitable serves. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html