Workflow - Tracking upstream repository with local patches
David Allouche
david at allouche.net
Thu Mar 6 20:30:58 GMT 2008
On Thu, Mar 6, 2008 at 9:12 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> I think I need the following - a "clean" branch from upstream, into
> which I periodically pull changes, and a local branch for each of my
> patches, which I maintain and periodically merge from my upstream
> mirror. To submit a patch, I'd bzr diff between my branch and the
> upstream mirror, and submit that.
That's correct. Another way is to produce the patch to send upstream
by doing "bzr merge yourbranch" into a checkout of upstream.
This means that you can use bzr merging magic to produce a patch that
applies quietly where a patch produced by a simple "bzr diff" would
cause the patch command to print "fuzz" messages. That reduces the
need for merging upstream into your branch.
> One issue with this is that my feature branches' history will be
> cluttered with regular "merge from upstream" checkins. I can see the
> value of this, but it will clutter the history of my feature
> development. Is there any way of avoiding this? Would the loom
> extension help here?
Loom would help, but at the cost at the turning each of your
individual commits into a merge.
If you can live with this, loom is ideally suited to this kind of
workflow, in particular it can be a great help if you send a patch
upstream in several parts.
> Does anyone have any suggestions as to how this workflow might be improved?
As Alexander says, you could use the rebase plugin instead of merging.
If I understand correctly, it will discard all your non-mainline
history, which may or may not be what you want.
More information about the bazaar
mailing list