Will re-basing support be added into Bazaar core ?
david at ar.media.kyoto-u.ac.jp
Mon Apr 20 08:23:48 BST 2009
David Timothy Strauss wrote:
> ----- "Russel Winder" <russel.winder at concertant.com> wrote:
>> This is of great interest. To date I have found no alternative to
>> rebase for keeping my feature branch changes "on top" of a mainline I
>> am tracking. Perhaps though I am too steeped in Subversion mindset? Or
>> perhaps this is a "Subversion repository as mainline but not allowed
>> to store Bazaar branches" problem only? If there is a way of avoiding
>> rebase and yet not having conflicts caused by changes in the tracked
>> branch, I would like to hear about it. I am happy using rebase when
>> I have to, but if I can avoid it without tortuous sophistry and
>> doublethink, I am all for it.
> (1) You branch from the mainline to develop a feature.
> (2) You work on your feature branch.
> (3) The mainline chugs ahead.
> (4) Prepare for merging the feature back into the mainline: (choose one)
> (4a) Your workflow: Rebase off the mainline.
> (4b) My workflow: Merge from the mainline back into the feature branch.
> (5) Resolve conflicts on the feature branch.
> (6) Merge the feature branch into the mainline.
> Either way, the result is the same: a common ancestor between the feature and mainline branches with changes only on the feature branch since the ancestor. This makes the feature -> mainline merge trivial, which I believe is your goal.
I don't know for Russel usecases, but for me, 5 and 6 are not the same,
they are very different. Merging is the same - from a tool POV. But with
rebase, you can update your branch on top of some mainline to keep a
patch up to date, which makes it easier for review by an *actual person*.
I use git rebase mainly for keeping patches up to date, so it is a bit
like mercurial queues or bzr looms. Except that it is much easier
because the workflow is exactly the same as for normal git operations.
More information about the bazaar