Re: [PATCH v3] user-manual: add advanced topic "bisecting merges"
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Nov 10, 2007, 11:16 UTC
- Message-ID
- <B622E814-D7D1-4DC8-A724-666BA0A1220F@zib.de>
- In-Reply-To
- <7vsl3emlpc.fsf@gitster.siamese.dyndns.org>
On Nov 10, 2007, at 11:36 AM, Junio C Hamano wrote:
Show 9 quoted lines
> Steffen Prohaska <prohaska@zib.de> writes: > >> ... >> +A solution is to linearize the history by rebasing the lower >> +branch on top of the upper, instead of merging. There were no > > Hmm. When I wrote it, I did not mean this as a "solution", but > as an illustration of how a merge heavy history and a linear > history have impact on bisectability.
I agree. This is what I understood. But later Johannes brought up the idea of naming it a "solution"; and some others liked this.
We should probably move the discussion to Chapter 5 "Rewriting history and maintaining patch series". Discussing pros and cons of merge versus rebase makes more sense there. The discussion would go right after "Problems with rewriting history". So, users should be warned not to rebase without thinking about the consequences. Another advantage is that users should have learnt more about git when they reach Chapter 5. Hence, it should be easier to follow the discussion.
Show 7 quoted lines
> So it is more like... > > On the other hand, if you did not merge at C but rebased the > history between Z to B on top of A, you would have get this > linear history [illustration here]. Bisecting between Z and > D* would hit a single culprit commit Y* instead. This tends > to be easier to understand why it is broken.
I'll take this...
Show 22 quoted lines
> For this reason, many experienced git users, even when they are > working on an otherwise merge-heavy project, keep the histories > linear by rebasing their work on top of public upstreams before > publishing (when able). An extreme example: merges from a few > top-level lieutenants to Linus in the kernel, e.g. David Miller, > are known to _almost always_ fast-forward for Linus. > > IOW, the description is to mildly encourage private rebasing to > keep the job of later bisecting (for potentially others) easier. > I realize I originally wrote as if C (merge) was made by the > same person as the person who ends up bisecting, but that is > not necessarily the case. Keeping the history without needless > merges tend to make _other_ people's lives simpler. > > And after encouraging the private rebasing, I would continue > like... > > But if you already made a merge C instead of rebasing, all > is not lost. In the illustrated case, you can easily rebase > one parent branch on top of the other after the fact, just > to understand the history and to make the history more > easily bisectable.
s/more easily bisectable/easier to bisect/ ?
Show 7 quoted lines
> Even though the published history should > not be rewound without consent with others in the project, > nobody gets hurt if you rebased to create alternate history > privately. After understanding the breakage and coming up > with a fix on top of D*, you can discard that rebased > history, and apply the same fix on top of D, as D* and D > should have the identical trees.
... and will prepare PATCH v4.
Steffen