Will re-basing support be added into Bazaar core ?

[David Cournapeau]

David Timothy Strauss wrote:
> ----- "David Cournapeau" <david at ar.media.kyoto-u.ac.jp> wrote:
>
>   
>> 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.
>>     
>
> Bazaar's Looms, unlike StGit and Mercurial Queues, fixes most of these issues. StGit allows public sharing at the loss of patch vs. commit semantics. Queues recognize patch semantics, but they're not publicly sharable. Looms have the best of both worlds: public sharability and recognition that patches aren't simply commits that get rewritten when the patch is improved or the upstream code changes. I think it's flawed to not have revision history for work done on a patch.
>   

in that case, looms are indeed better. I think having the 'true' history
does not matter, prefer a 'pretty' history and enjoy the rebase
simplicity. So it looks like we use tools which suit us better, which is
kind of the point.

> I'm not sure what you mean by "testability" with these tools. In Looms, the final applied patch (like each patch) is simply a branch.
>   

I am sorry, I don't know the exact expression - I was referring to what
was previously mentioned about rebasing breaking the ordering, and thus
having tested a branch with 3 commits A->B->C did not imply any
successful run once this is rebased on another branch. This seems to
matter a lot to bzr's philosophy and bzr's developers.

cheers,

David