Steffen Prohaska <prohaska@xxxxxx> 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.
-
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
