Thread (21 messages) flat view 21 messages, 8 authors, 2016-06-15

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

From: Brian Gernhardt <hidden>
Date: 2016-06-15 22:43:48

On Nov 8, 2007, at 9:51 AM, Benoit Sigoure wrote:
You're missing the point.  Johannes suggested that you rebase *only*  
for bisecting purpose.  Once you find the culprit commit, throw away  
your rebased stuff.  I've never thought about doing this myself, but  
it's a very clever way of tackling this problem.  It's slightly less  
convenient if you need to bisect a large portion of the history  
(that involves many branches and merges) because in this case we'd  
like to have a magic git-linearize-history <start-treeish> <end- 
treeish>.  Unless this is already easily doable with git-rebase?

I don't think you have to linearize it before bisecting.  If you  
bisect and discover that it was due to a merge, then you can rebase  
*that merge* to discover what part of the merge caused the issue.

~~ Brian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help