Thread (21 messages) flat view 21 messages, 8 authors, 2016-06-15

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

From: Steffen Prohaska <hidden>
Date: 2016-06-15 22:43:48

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

quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help