On Nov 8, 2007, at 8:19 AM, Johannes Sixt wrote:
Steffen Prohaska schrieb:
+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.
How about leaving the text as is and adding an introductory
paragraph at the beginning of the section?
I.e:
This section discusses how gitlink:git-bisect[1] plays
with differently shaped histories. If you did not yet
publish a branch you can use either gitlink:git-merge[1] or
gitlink:git-rebase[1] to integrate changes from a second
branch. The two approaches create differently shaped
histories. So it might be interesting to know about the
implications on gitlink:git-bisect[1].
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
