Collision branches

James Westby jw+debian at
Thu Sep 8 20:56:27 UTC 2011

On Thu, 8 Sep 2011 14:51:44 +1000, Martin Pool <mbp at> wrote:
> I looked into a few of them and they weren't all clearly due to quilt
> problems, but perhaps most of them are (or I didn't understand the
> cause from a glance.)

Unfortunately it's necessary to look at the importer log for the package
to see why the importer felt it necessary to file the merge proposal.

This is because the diff you are seeing is the result of merging the
branch in to the new tip, but the importer decides based on the diff of
the two revisions. These frequently differ and mean that looking at the
merge diff doesn't tell you why the importer chose to do that
(particularly if the merge diff is empty.)

Perhaps that's the wrong check, but that's the way it is currently.

> I think we can handle this without blocking on looms by doing a
> smarter merge that unapplies and reapplies the patches.  There is some
> work towards this in eg <> which
> Jelmer is working on - we may need extra work to hook it up into the
> udd importer.

Would it also need to be used by LP when generating the merge diffs?

> What we should probably do next is look at the merge proposals that
> were filed and work out whether each one
> - is a real conflict in a sensible form
> - is not a real conflict and shouldn't be generated at all (some have zero diff)
> - could be either avoided or better presented by smarter quilt
> handling or something else

That would be good. Is someone able to look at this analysis?



More information about the ubuntu-distributed-devel mailing list