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

Steffen Prohaska schrieb:

On Nov 8, 2007, at 10:53 AM, Johannes Sixt wrote:

quoted

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.

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