+TODO
+ more tests, see "todo" in gdr-editw
+ reference docs
+ git-debrebase(5) data model
+ git-debrebase(1) command line
+ tutorial
+ dgit-maint-debrebase(7)
+
+ clean up remains of NOTES and README
+
+ arrange for dgit to automatically stitch on push
+
+# git-ffqrebase start [BASE]
+# # records previous HEAD so it can be overwritten
+# # records base for future git-ffqrebase
+# git-ffqrebase set-base BASE
+# git-ffqrebase <git-rebase options>
+# git-ffqrebase finish
+# git-ffqrebase status [BRANCH]
+#
+# refs/ffq-prev/REF relates to refs/REF
+#
+# git-debrebase without start, if already started, is willing
+# to strip pseudomerges provided that they overwrite exactly
+# the previous HEAD
+# xxxx is this right ? what matters is have we pushed
+# I think in fact the right answer is:
+# git-debrebase always strips out pseudomerges from its branch
+# a pseudomerge is put in at the time we want to push
+# at that time, we make a pseudomerge of the remote tracking
+# branch (if raw git) or the dgit view (if dgit)
+# for raw git git-ffqrebase, do want preciseley to record
+# value of remote tracking branch or our branch, on start, so we
+# overwrite only things we intend to
+# the previous pseudomerge check for tags and remote branches ?
+
+
+=========
+
+special commit tags
+overall format
+ [git-debrebase[ COMMIT-TYPE [ ARGS...]]: PROSE, MORE PROSE]
+
+[git-debrebase: split mixed commit, debian part]
+[git-debrebase: split mixed commit, upstream-part]
+[git-debrebase: convert dgit import, debian changes]
+[git-debrebase breakwater: convert dgit import, upstream changes]
+
+[git-debrebase upstream-combine . PIECE[ PIECE...]: new upstream]
+[git-debrebase breakwater: new upstream NEW-UPSTREAM-VERSION, merge]
+[git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog]
+
+[git-debrebase: gbp2debrebase, drop patches]
+[git-debrebase breakwater: declare upstream]
+[git-debrebase pseudomerge: stitch]
+
+m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
+
+Every breakwater commit must be a merge. In principle, this is not
+necessary. After all, we are relying on the
+ [git-debrebase breakwater: ...]
+commit message annotation in "declare" breakwater merges (which
+do not have any upstream changes), to distinguish those breakwater
+merges from ordinary pseudomerges (which we might just try to strip).
+
+However, the user is going to be doing git-rebase a lot. We really
+don't want them to rewrite a breakwater base commit. git-rebase
+trips up on merges, so that is a useful safety catch.
+
+
+=========
+