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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Nov 8, 2007, 13:22 UTC
Message-ID: <47330D78.3040808@viscovery.net>
In-Reply-To: <97F64156-A457-4BC1-84BE-108369FFD18C@zib.de>

Steffen Prohaska schrieb:

Show 11 quoted lines

> 
> On Nov 8, 2007, at 10:53 AM, Johannes Sixt wrote:
>> The text that the patch amends is 
>> about bisecting history that reveals that a merge commit breaks, which 
>> is not helpful, and then how to find where and what and why the 
>> breakage really was introduce.
>>
>> And the answer to "how to find" is to rebase and bisect in the rebased 
>> history.
> 
> Do you use rebase like this in real life?

Why is this relevant?

You've written a superb addendum to the user manual, but IT TALKS ABOUT BISECTION, and is not a guideline when to use merges and when to rebase.

It better not be meant as such. Consider an integrator who has just merged two histories, both of which are available publically. Pushing out a rebased history IS NOT AN OPTION. If the poor fellow for the heck of it has no choice but to find the bogus commit, then your instructions are worth a thousand bucks - even if the rebased history is otherwise useless -, but any guidelines how to construct histories are IRRELEVANT for his case.

Show 5 quoted lines

> But now I'm wondering if your suggestions of rebasing only for
> locating the evil commit is feasible in reality. You may need
> to solve a lot of merge conflicts if you rebase a larger part
> of the history. If you do not have them in your rerere cache
> this might be time consuming. ...

During the rebase you will see the same conflicts that you also had during the merge, even simpler ones (because they are - hopefully - broken down into smaller pieces). If your merge was clean (as was suggested in the patch), then you won't see a lot of conflicts during the rebase, either.

-- Hannes