From: Ralf Wildenhues <ralf.wildenhues@gmx.de>
Date: Sun, 04 Nov 2007 11:23:02 GMT
Subject: Re: [PATCH] user-manual: add advanced topic "bisecting merges"
Message-ID: <20071104112302.GA2119@ins.uni-bonn.de>
In-Reply-To: <11941677732664-git-send-email-prohaska@zib.de>

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