Workflows, rebase, patch theory

[Ian Clatworthy]

Daniel Pittman wrote:

> 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.

I guess different people have different opinions as to what constitutes
merge "noise". I personally think that one merge-related entry in a log
is preferable to zero (and obviously preferably to two or more).

Given that merging in Bazaar doesn't implicitly commit, it's easy to:

1. do the merge
2. run the test suite
3. tweak things to fix any problems
4. commit

With that process pattern, "broken merge + fixed" pairs ought to be
rare. Using a tool like PQM to manage your main branch (by automating
this) is another option.

The only time *I* find myself wanting rebase is when I've been
developing on a (private) experimental branch for several days and I
want to cherrypick a series of changes into a public branch. More often
than not, the experimental branch has reached a point where I realise
something like "OK - this is going to take some time/discussion to make
this overall feature work well, but there's stuff I can and ought to
harvest and publish now." When we support cherrypicking properly
(discussed in the London sprint but
http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms is rather light on
the subject), I'm hoping to use that feature instead, assuming one will
be able to cherrypick a series of changes.

In summary, rebasing is *occasionally* useful, particularly if you must
interact with an upstream project by providing a series of patches. But
it should be used sparingly given it breaks merge tracking, making
collaboration with others harder. In Bazaar at least, there are
frequently better ways of achieving the same goal, e.g. using PQM,
running tests after merge but before commit, bzr-svn, merge directives, etc.

Ian C.