Re: [PATCH v3] user-manual: add advanced topic "bisecting merges"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 10, 2007, 10:36 UTC
- Message-ID
- <7vsl3emlpc.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <119468808499-git-send-email-prohaska@zib.de>
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. 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.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. 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.