Fixing rebase rather than avoiding it

[Talden]

Why do we always seem to divide into groups of extremes - maybe it's
only the extremes that a vocal.

One group seems to consider the merged branch-history burdensome and
would prefer to always remove it. The other group basks in deific glee
at their tools refusal to allow the editing of the DAG (regardless
whose DAG it is).

There must be some middle ground (though I think I'm about to miss it)...

Surely it is the branch owners right to express their changes and the
evolution of those changes as they see fit.  After all, they're my
changes until you accept them.

I certainly wouldn't expect anyone to be allowed to submit a change to
public branch that changed it's published history but I would expect
the the other participants to respect the freedom of a private branch
owner to modify their unpublished history and allow them the tools to
make that effort practical.

* This allows pruning orphaned content (content that was both added
and then removed within the range of incoming revisions of a merge
proposal) from history of the submission branch before it becomes a
burden on the project proper.
* It gives the opportunity to separate changes that should be
delivered separately but have been mixed into a single branch yet not
abandon the evolution of those changes.
* It enables an improvement in the quality of history with the option
to correct inappropriate branch-nicks, mistyped logs and bug numbers.
* Lets a developer clarify their history for purposes of review where
a large change might not be practical to deliver in pieces but would
be difficult to review as a whole by reducing what could be a long and
extensive history or trial, error and discovery into meaningful steps.
* Let's branches with content encumbered with licensing or privacy
issues be delivered/donated in a form that retains as much of its
genesis as possible (sometimes making it easier to understand a bugs
inception and therefore it's scope and likely resolution).
* In a commercial context where the quality of history is sometimes
considered part of the reviewable content, this allows for some
corrective action in response to review beyond doing it all again by
hand (or rather 'merge... forget merge... commit' cycles).

I shouldn't have to write code to get bazaar to do it and I'd like not
to have to depend on it from plugins which lag the core development
and perhaps don't have the same determination for correctness -
something I appreciate in anything that alters my history.

It seems to me that making Bazaar a more flexible tool in this manner
will only be a bad thing if we harm the UI for those that do not wish
to use it. In every other way it makes Bazaar more inclusive. Bazaar
supports many workflows now and more are supported with this
functionality - with it Bazaar will be useable/acceptable in more
projects.

I hope that growing the 'rebase' type functionality into a rich UI
avoids the many years of pain felt by some in the Subversion community
- whenever the 'obliterate' functionality was mentioned half the major
Subversion contributors (at the time) practically turned into the next
Inquisition. Their chief weapon is...

--
Talden