Will re-basing support be added into Bazaar core ?

[David Cournapeau]

David Timothy Strauss wrote:
>
> 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.
>   

indeed, rebase is not necessary for identifying things particular to a
branch. You certainly don't use it like this in git: features for branch
comparison like bzr missing and the likes are available in git as well
(it is more powerful because almost every command which take different
revisions in git can use different branch names as well, whereas bzr
usually treat branch and commits differently, at least at the UI-level).

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

That's the disagreement, I guess :) I think rebase is simpler and better
than looms for many cases (that's one case where git model is actually
simpler than bzr or mercurial IMHO). Rebase drawbacks and pitfalls are
shared by looms (public sharing, "testability"). Internally, tt is
essentially a reordering of your commits for both rebase and looms
AFAICS, so this is expected.

I prefer a core set of commands which I can use for different workflows
- bzr "philosophy" seems different here, with a plugin (loom) to support
the workflow that you can build by yourself with git + rebase. That's
fine - both approaches have their merit; I just wanted to justify the
rebase-based workflow in a git context.

cheers,

David