Re: [PATCH] user-manual: add advanced topic "bisecting merges"

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