Workflow - Tracking upstream repository with local patches

[David Allouche]

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.