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

> Hi Steffen,
>
> On Nov 7, 2007, at 10:50 PM, Steffen Prohaska wrote:
>
> Some more comments below.  Sorry for not spotting these earlier.

>> +later when you have a better understanding of git.
>> +
>> +[[bisect-merges]]
>> +Why bisecting merge commits can be harder than bisecting linear  
>> history
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> ~~~
>> +The following text is based upon an email by Junio C. Hamano to
>> +the git mailing list
>> +(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http:// 
>> marc.info/?l=git&m=119403257315527&w=2]).
>> +It was slightly adapted for this manual.
>> +
>> +Bisecting merges can be challenging due to the complexity of
>> +changes introduced at a merge.  Bisecting through merges is not a
>
> s/at a merge/& point/ ?

>> +added a new calling site for that function at commit Y.  The
>> +commits from Z leading to B all assume the old semantics of that
>> +function and the callers and the callee are consistent with each
>> +other.  There is no bug at B, either.
>> +
>> +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
>
> s/adjustment/&s/