Workflows, rebase, patch theory

[Talden]

>  > AIUI, git users tend to use this to keep their changes up to date
>  > and "ready for submission" with respect to a trunk. The advantage is
>  > you don't have commits like "Merge bzr.dev" interspersed with your
>  > own changes.
>
>  Okay. This does seem to be a main complaint against Bazaar and
>  Mercurial by Git or Darcs users. I don't understand why it's desirable
>  to hide merges in the history, especially against...

Well I guess because in a longish running branch that has high
dependencies with other branches landing in the upstream you can get a
lot of merge-noise.  The branch commits might look like this:

  Added API stubs for FeatureX
  Added tests for API
  Tied into workflow event model
  Merge from upstream Foo
  Added new entities
  Merge from upstream Foo
  Merge from upstream Foo
  Completed finder tools
  Merge from upstream Foo
  Updated Tests
  Integration merge with Foo
  Tweaks from Review.  Added a test.

Rebased (sensibly, obviously you could squish some of the branch
commits too but that would absolutely mean throwing away possibly
interesting milestones) this could look like this:

  Added API stubs for FeatureX
  Added tests for API
  Tied into workflow event model
  Added new entities
  Completed finder tools
  Updated Tests
  Tweaks from Review.  Added a test.

The merge revisions add nothing of value other than perhaps a timeline
(since rebasing has to squish the timeline to follow on from the new
branch-point).  None of the intermediate branch commits were
deliverable before branch completion so the rebasing is unlikely to
have degraded their usefulness - the extra merge noise does however
degrade the usefulness of the history.

In an ideal world all tasks would involve a handful of commits over a
day or two and not require these upstream merges... Not all projects
fit this model.

Delivering a feature back to the mainline in our case requires it to
be finished and finishing it without complex refactoring efforts at
the end of some branches means regular merges from mainline into the
branch.  We are, naturally, striving to stabilise APIs to the point
where there is little coupling between concurrently active work-tasks
within the team... If we had to reach such a utopia before Bazaar were
useful we would never get approval to adopt it - for these projects
rebasing is the boon that lets us benefit from all of the other good
things about bazaar.

(That said, I'm still to get approval for its use)

--
Talden