Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
- From
Brian Gernhardt <benji@silverinsanity.com>
- Date
- Nov 8, 2007, 18:38 UTC
- Message-ID
- <DE41BBF5-DD69-4A6B-97EE-ED42C8B1B616@silverinsanity.com>
- In-Reply-To
- <5498B368-053A-424E-B901-A55B66FF5801@lrde.epita.fr>
On Nov 8, 2007, at 9:51 AM, Benoit Sigoure wrote:
Show 8 quoted lines
> 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