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