Hello Steffen, A couple of language nits: * Steffen Prohaska wrote on Sun, Nov 04, 2007 at 10:16:13AM CET: > +Suppose that on the upper development line, the meaning of one > +of the functions existed at Z was changed at commit X. The s/functions/& that/ > +commits from Z leading to A change both the function's > +implementation and all calling sites that existed at Z, as well > +as new calling sites they add, to be consistent. There is no > +bug at A. [...] > +You merge to create C. There is no textual conflict with this > +three way merge, and the result merges cleanly. You bisect > +this, because you found D is bad and you know Z was good. Your > +bisect will find that C (merge) is broken. Understandably so, > +as at C, the new calling site of the function added by the lower > +branch is not converted to the new semantics, while all the > +other calling sites that already existed at Z would have been > +converted by the merge. The new calling site has semantic > +adjustment needed, but you do not know that yet. You need to > +find out that is the cause of the breakage by looking at the s/that/that that/ > +merge commit C and the history leading to it. [...] > +If you linearlize the history by rebasing the lower branch on > +top of upper, instead of merging, the bug becomes much easier to s/upper/the &/ > +find and understand. Your history would instead be: [...] Cheers, Ralf - 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
