Re: Cherry picking instead of merges.
Show 16 quoted lines
> IOW, let's say that you really do bisect things down to a merge and cannot
> see what the fault in that merge is, you can literally do
>
> # create a test-branch with the 'remote' side of the merge
> git checkout -b test-branch merge^2
>
> # rebase that remote side on top of the local side
> git rebase merge^
>
> and now you've linearized the merge temporarily just to be able to bisect
> in that temporary branch what the bad interaction is. But once you've
> bisected it, the temporary branch is again just junk - there's no real
> value in saving it, because once you know _why_ the bug happened, you're
> just better off going back to the original history and just fixing it (and
> documenting the bug through the fix, rather than by addign extra-ugly
> history).
FWIW, the same thing in different words is written in section
"Why bisecting merge commits can be harder than bisecting linear history"
of Documentation/user-manual.txt.
-- Hannes
Johannes Sixt <j.sixt@viscovery.net>