On Nov 8, 2007, at 2:22 PM, Johannes Sixt wrote:
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.
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.
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
-
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
