On Thu, 8 Sep 2011 14:51:44 +1000, Martin Pool <m...@canonical.com> 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 <https://bugs.launchpad.net/bugs/608675> 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? Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
