Re: Cherry picking instead of merges.

[Johannes Sixt <j.sixt@xxxxxxxxxxxxx>]

Linus Torvalds schrieb:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html