Workflows, rebase, patch theory

[James Henstridge]

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:
>
>  From:
>
>   o--------o---------o
>    \---o-----o----o-----o
>
>  To:
>   o--------o---------o
>                      \---o-----o----o-----o
>
[snip]
>  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.

James.