Will re-basing support be added into Bazaar core ?

[David Timothy Strauss]

----- "David Cournapeau" <david at ar.media.kyoto-u.ac.jp> wrote:

> Yes, that's the core point - for me (and Russel as well if I
> understand his workflow correctly), changes on top of history *is *the end.
> That's the whole purpose, because it means that understanding what's
> happening in the history is easier. The purpose of rebase is to alter the
> history to make it prettier. If you think that's useless, then rebase is
> useless.
> 
> It is a tradeoff: I don't see any way to get both "every commit is
> tested" and "altering patch order" at the same time, they are pretty
> much antithetic. I prefer giving up the every commit is tested (as
> long as the merge into the current mainline is tested), and keeping
> rebasing, but that's a preference. Given bzr developers POV (which is opposite
> to my own preference stated here), it sounds logical to avoid rebase as
> a core feature.

Running "bzr missing --mine-only [mainline]" on the feature branch provides a log of revisions unique to the feature branch, so I don't think rebasing is necessary to easily identify the revisions comprising the feature in development.

The only difference is that a "bzr diff" on a rebased revision will show a diff that's is more-or-less against the current mainline. I can understand why that's desirable, though a Loom-like model with stacked branches is more appropriate for a project needing to constantly maintain patches versus the mainline.

Finally -- and I haven't verified this -- but you should be able to use "bzr diff --old=[mainline] -rN..M" to view a single revision versus the mainline, still without rebasing.