+Looking from the tip of the interchange view, it is I think always
+possible to classify these commits appropriately: pseudomerges are
+fairly obvious (if all three trees are identical, we descend to the
+parent with the most recent commit date). The `@' special merge is
+the only non-pseudo merge and has a special form; also, it will be
+generated only by our tools so can have an annotation in the commit
+message.
+
+So it would be possible to write a `git-debrebase' tool which would
+take (for example) B4, above, and be able to perform functions like:
+
+ * Strip pseudomerges: Rewrite the current branch so it contains no
+ pseudomerges, turning ...B3 into ...@-A-1-2-B3. (This should
+ make a note, in your .git/ somewhere, of the original branch
+ tip so that it can be overwritten with a pseudomerge.)
+
+ * Cleanup branch: Reorganise the current branch so that the debian/
+ changes come first, turning -@-A-1-2-B3 into ...@-A-B-1-2-3.
+
+ * New upstream rebase: Start rebasing onto a new upstream version,
+ turning ...#..@-A-B-1-2-3 into (...#..@-A-B-|...#'-)@'-1-2. This
+ would be a wrapper around git-rebase, which prepares @' and then
+ tries to rebase 1 2 onto @'. So if you ask for an interactive
+ rebase @' doesn't appear in your commit list.
+
+ Note that the construction of @' cannot fail because @' simply
+ copies debian/ from B and and everything else from #'. (Rebasing A
+ and B is undesirable. We want the debian/ files to be non-rebasing
+ so we can `git log' and get the packaging history.)
+
+ * Record pseudomerge. This is like "committing" your patch queue.
+ The LH parent is taken from the previously recorded tip. (We could
+ perhaps check that this is consistent with what we see in
+ debian/changelog, but that is not a sufficient check so the
+ recorded tip check is primary.)
+
+Maybe some of these operations should automatically edit
+debian/changelog.
+
+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.)
+
+Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
+> Does the [breakwater] branch contain debian/ alone?