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

From: Steffen Prohaska <prohaska@zib.de>
Date: Nov 8, 2007, 14:55 UTC
Message-ID: <217E7104-312D-4D0C-BC66-C4829779C216@zib.de>
In-Reply-To: <47330D78.3040808@viscovery.net>

On Nov 8, 2007, at 2:22 PM, Johannes Sixt wrote:

Show 12 quoted lines

> Steffen Prohaska schrieb:
>> 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?

Well, I don't want to give recommendations that are not tested in real life. Maybe the solution turns out to be less practical than it should be theoretically.

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

BTW, I only took what Junio wrote during a recent discussion on the list, polished it a bit and sent it as a patch. I'm only the editor, not the original author. That doesn't mean I wouldn't care about the text. I'm willing to improve the text. But all the cheers really should go to Junio.

Show 7 quoted lines

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

Ok, I see your point. I'll mention these points.

Show 11 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.

Yeah. I'll try to mention this at an appropriate place.

	Steffen