Workflows, rebase, patch theory
james at jamesh.id.au
Wed May 7 07:25:58 BST 2008
2008/5/7 Daniel Pittman <daniel at rimspace.net>:
> The operation is, essentially, to change the starting point of a graph
> of changes from one point to another:
> The advantage is that you are presented with a very clean development
> history: when you merge the rebased branch into the source branch you
> don't see a lot of merge noise or whatever during the development cycle.
> For a long-lived branch this can be a significant volume of noise
> avoided, and can also ensure that your main branch *always* compiles,
> because you never have a "broken merge + fixed" pair of changes, only a
> "correct merge" single change.
Of course, this is only true if you run the test suite on the rebased
version of each revision, which people seldom do.
If there is a semantic conflict between the first revision of your
un-rebased branch and the head revision of the upstream, it is
entirely possible that the revision can be rebased without a textual
conflict but fail to compile (e.g. renaming a variable, altering a
list such that the indices change, etc).
The semantic conflict might be fixed by a later revision on your
branch so that the head of the rebased branch passes, but the
operation can easily take you from a graph of correct revisions to a
linear sequence containing broken revisions.
More information about the bazaar