Merging before sending a patch ?

[Martin Pool]

On Thu, Mar 27, 2008 at 12:00 PM, Xavier Maillard <xma at gnu.org> wrote:
> Hi,
>
>  Say I have created a branch foo.dev from foo.
>
>  I am hacking on foo.dev and in parallel, food is updated.
>
>  At some point I feel ready to submit my changes as a patch to the
>  team.
>
>  I do bzr send -o (for example) but it will only take new
>  revisions to put them into my output.patch. How do I "rebase" my
>  work on top of the updated food ? Do I need to bzr pull into foo
>  and then bzr send or is there another and simpler way ?

If you want you can merge from trunk, commit into your branch, then
send it.  The diff included will still look reasonable and it will
give you a chance to do any textual or semantic conflict resolutions.

However, I think for Bazaar development people generally don't do
this, but rather just send without merging to trunk; this is for a few
reasons:

Generally we want to review what's new in the branch, and the merge
and conflict resolutions are not very relevant to that.

Even if you get up to date with the trunk at the time you send your
merge, there may be more commits while it is being reviewed, and so
further resolution may be needed later on anyhow.  At that time the
person doing the merge can either fix it up, or bounce it back and ask
you to update.

Hopefully people are fixing things and merging back on a fairly short
cycle, rather than accumulating very large branches, and so the
conflicts should be small.

-- 
Martin <http://launchpad.net/~mbp/>