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 - 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
