-The only thing that this can't easily do is permit nonlinear (ie,
-merging) history on the `packaging-only' branch, because upstream
-might contain debian/ files too, so it is not possible to distinguish
-a merge of two `packaging-only' branches from the special merge `@'.
-(Indeed I since upstream might copy debian/ from us, I think it is not
-easy to reliably distinguish the two parents of a `@'. In the most
-exciting edge case, upstream might `git merge' a previous instance of
-our interchange view, but I think even then everything still works.)
+Nonlinear (merging) history in the interchange branch is awkward
+because it (obviously) does not preserve the patch queue.
+
+Nonlinear (merging) history in the `packaging-only' branch is OK, if
+we could generate it. We will use the commit message annotation to
+distinguish a merge of two `packaging-only' branches from the special
+merge `@'. (Indeed I since upstream might copy debian/ from us,
+without the annotation and knowledge of the construction order it is
+not easy to reliably distinguish the two parents of a `@'. In the
+most exciting edge case, upstream might `git merge' a previous
+instance of our interchange view, but I think even then everything
+still works.)