Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

David Timothy Strauss writes:

 > [Rebasing] can be "evil" from the perspective that existing branch
 > history is sacred and should not be altered.

Altering history is an implementation detail.  Eg, it won't happen in
git, because it's impossible in git.  The point is that in git history
is encapsulated in commits, whose truenames cannot change.  "Branches"
are merely special nicknames for particular commits, which have the
feature that if a new commit is created with the parent being the tip
of the active branch, it will advance the pointer to the new commit.

It is possible to "lose history" in git by first moving the branch ref
to a non-descendent commit, then allowing the reflog and the commit to
be garbage-collected, of course.  But if you turn off the garbage
collector, git will never lose history (short of a bug or hardware
failure, of course).  And it can't alter history at all.

 > I also have to question the purpose of rebasing and whether there's
 > a different, innovative alternative that also solves the (alleged)
 > workflow problems rebasing is used to solve. I've done some pretty
 > crazy feature/vendor/etc. branches for Drupal, and I've not needed
 > to rebase. I'd like to see some realistic use cases that only
 > rebasing can currently solve.

If the workflow demands a linear sequence of commits, but permits
concurrent commits, rebasing is necessary.  The only other solution
I'm familiar with is Darcs, where a branch is a set, not a sequence.

 > At this point in my arguments, you're probably thinking, "So, just
 > don't use rebasing." But I strongly believe that Bazaar core should
 > provide a safe, coherent set of tools by default.

Well, it doesn't.  But that has little to do with what operations it
provides.  It's an issue of design and implementation of the history
database.  Bazaar's branch-centric (ie, linear) design makes it very
difficult to safely provide DAG operations other than commit and merge.

 > For each problem, we should try hard to find one really great
 > solution rather than build a smattering of related utilities (like
 > rebase) that can cleverly be combined to solve the problem.

Rebase is not a utility.  It is the name of the VCS operation that
could be defined as presenting a particular linearized account of
partially ordered history.  Eg, it is implicitly done by every log
operation.  It is simply[1] a choice of a particular total order on
the portion of a DAG between a fork and a merge.


Footnotes: 
[1]  Actually, conceptually it's quite complex, because different
total orders will often result in textual conflicts.  Then to know
what the correct resolutions of the conflicts are, one needs a theory
of patches.  But that's not relevant to safe implemention of manual
rebasing.