Re: [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..."

> On Sat, 10 Nov 2007, Steffen Prohaska wrote:
>> +
>> +But if you already made a merge C instead of rebasing, all
>> +is not lost.  In the illustrated case, you can easily rebase
>> +one parent branch on top of the other after the fact, just
>> +to understand the history and to make the history more
>> +easily to bisect.
>
> I simply don't think this is true. 
>
> You can *not* easily rebase after the fact. Both the parents may have lots 
> of merges independently of each other, and rebase won't be able to do 
> *anything* with such a case. In fact, the only reason you think you can 
> easily rebase after-the-fact is that you made the example history be 
> trivial. In real life, if the example history is that trivial (just a 
> single merge of two otherwise linear histories), you'd probably generally 
> not have this problem in the first place.
>
> The facts are:
>
>  - git bisect can handle merges quite well, and points to the right 
>    commit (which is *usually* not a merge).
>
>  - but merges by definition introduce changes from two independent lines 
>    of development, and while both lines may work well on their own, it is 
>    possible that (a) the merge itself was done incorrectly or (b) the two 
>    (or more) features that were introduced simply clash.
>
>  - "git rebase" won't do a thing for this after the fact, except in 
>    trivial cases, and even then it will generate a new history that simply 
>    isn't compatible with the original history, so while it could in theory 
>    help bisect things further in some limited and simple cases, in general 
>    it's simply not that useful an approach.
>
> ..and I think it's simply wrong to even *try* to imply that "git rebase" 
> can somehow change any of this.