Merging before sending a patch ?

[Xavier Maillard]

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

Could it be mentionned somewhere (it may be already the case, I
did not check though) if it is the project policy ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org