Improving merge-upstream

James Westby jw+debian at
Tue Sep 28 21:16:39 BST 2010

On Tue, 28 Sep 2010 21:39:54 +0200, Vincent Ladeuil <v.ladeuil+lp at> wrote:
> There is a merge proposal that goes in this direction pending review at:
> (with pre-requisites).


>     > 4) Remembering the upstream branch.
>     > merge-upstream takes an optional upstream branch. Currently there are
>     > cases where one person supplies it, but the next doesn't, and that's not
>     > ideal, as you get a discontinuity, and there can be extra conflicts in
>     > future due to added files.
> Still related to parallel imports ?

It is parallel imports, yes.

> Martin mentioned recently that we could special-case merge to relax the
> conflicts for different file-ids by checking the paths involved. That
> would not solve the parallel import problem but it may help for the
> packaging and upstream branches relationship.

I think so. This is beyond just that problem though, in that it could be
recording a richer ancestry that it will if you forget the upstream

>     > Therefore I would like if if, similar to e.g. bzr merge, if you supply a
>     > branch once it is remembered and used again.
> That's clearly a case where some config file should be versioned and
> shared even if it needs to be versioned in a specific way (the reference
> to the upstream branch is a live data that doesn't flow in the same way
> than the upstream code or the packaging data (or does it?)).

It's slightly independent, yes. I would put it in
.bzr-builddeb/default.conf, as that is a good start.

> Would you qualify this upstream branch as a data shared by a set of
> branches but for which updates are never reverted ?

I'm not sure I follow this. I could concoct a situation in which it is

> Couldn't you use an ancestry check against the last merged revision ?

That could make sense.

It wouldn't stop partially unrelated things being merged. If you are
merging a release from a stable branch then you don't want to merge



More information about the ubuntu-distributed-devel mailing list