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

Steffen Prohaska wrote:

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

quoted

Andreas Ericsson schrieb:

quoted

Johannes Sixt wrote:

quoted

Steffen Prohaska schrieb:

quoted

On Nov 8, 2007, at 8:19 AM, Johannes Sixt wrote:

quoted

Steffen Prohaska schrieb:

quoted

+If you linearize the history by rebasing the lower branch on
+top of the upper, instead of merging, the bug becomes much 
easier to
+find and understand.  Your history would instead be:

At this point I'm missing the words

    The solution is ...

I.e.:

The solution is to linearize the history by rebasing the lower 
branch on
top of the upper, instead of merging. Now the bug becomes much 
easier to
find and understand.  Your history would instead be:

Hmm. It might be a solution if you did not publish history.

This is about finding the commit that introduced a bug. Once you 
found it, better: you know how to fix the bug, you are expected to 
throw away the rebased branch, not to publish it! Maybe a note along 
these lines could be appended:

Now that you know what caused the error (and how to fix it), throw 
away the rebased branch, and commit a fix on top of D.

Well, if rebasing becomes the standard for normal development, it's 
hardly
right to throw it away, is it? I like Steffen's suggestion better.

There is a big misunderstanding. 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?

I thought of the text as background information that might
be helpful for users who want do decide wether to merge or
to rebase. The problem described may be valuable information
supporting a decision about a recommended workflow for a group
of users.

My personal conclusion was: I'll accept the danger of complex
merges that might be hard to bisect. I now understand this
risk, but I nonetheless prefer the simplicity of a merge
based workflow. This avoids the danger that published history
gets rewritten.

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

It is no great chore to put one merge-parent on top of another
and then re-run bisect on the result. git-bisect could even be
taught to do that by itself.

quoted

My initial complaint was that in the flow of reading the instructions 
the pointer to "the solution" was missing. Rather, at the point where 
the reader is supposed to think "ah, yes, that's how to do it", there 
is the conditional statement "If you linearize history". My suggestion 
is to put a big emphasis on the solution by using the words "The 
solution is".

Now, the user can *always* rebase one of the branches on top of the 
other, even if both histories are already published. *But* if both 
were indeed published, then the rebased history must be thrown away, 
and the only thing you learnt from it was where and what and why the 
breakage really was introduced.

Of course we could include a few "ifs" and "unlesses" (about published 
histories), before suggesting to throw away rebased history. But once 
the task is accomplished (find the bogus commit), throwing away the 
rebased history (and continuing at commit D) is always correct, but 
keeping it (and continuing at D*) is not.

... So, again, the question for me is if someone does use
rebase in reality in the way that you suggests. Do you?

I don't, but if I'd thought a bit further I would have on at least one
occasion in the past. Instead I spent two days manually auditing every
commit of several branches.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231