X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=NOTES.git-debrebase;h=f32cf87ec78e894d474bd149e4c7d3603fd9aaad;hp=09237d5973cda501e24ecb4acb4b73c7e4a45a51;hb=dc6bcd256e972c2bc8a65e077c27ed57745c76eb;hpb=ac6f8cf1df126cf79e08d431932b76cec83f443a

diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index 09237d59..f32cf87e 100644
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -1,50 +1,15 @@
 TODO
-   reference docs
-      git-debrebase(5)   data model
-      git-debrebase(1)   command line
    tutorial
       dgit-maint-debrebase(7)
       someone should set branch.<name>.mergeOptions to include --ff-only ?
 
-   clean up remains of README
-
    arrange for dgit to automatically stitch on push
+     dgit push usually needs to (re)make a pseudomerge.  The "first"
+     git-debrebase stripped out the previous pseudomerge and could
+     remembeed the old HEAD.  But the user has to manually stitch it.
+     To fix this, do we need a new push hook for dgit ?
 
-=======================================
-
-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 anchor: convert dgit import, upstream changes]
-
-[git-debrebase upstream-combine . PIECE[ PIECE...]: new upstream]
-[git-debrebase anchor: new upstream NEW-UPSTREAM-VERSION, merge]
-[git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog]
-
-[git-debrebase convert-from-gbp: drop patches]
-[git-debrebase anchor: declare upstream]
-[git-debrebase pseudomerge: stitch]
-
-[git-debrebase convert-to-gbp: commit patches]
 
-m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
-
-Every anchor commit must be a merge.  In principle, this is not
-necessary.  After all, we are relying on the
-    [git-debrebase anchor: ...]
-commit message annotation in "declare" anchor merges (which
-do not have any upstream changes), to distinguish those anchor
-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 an anchor commit.  git-rebase
-trips up on merges, so that is a useful safety catch.
-
-=======================================
 
 workflow
 
@@ -64,6 +29,40 @@ workflow
   commit / git-debrebase / etc.            strips last pm, but arranges
                                            that remade pm will incorporate it
 
+
+# problems / outstanding questions:
+#
+#  *  dgit push with a `3.0 (quilt)' package means doing quilt
+#     fixup.  Usually this involves recommitting the whole patch
+#     series, one at a time, with dpkg-source --commit.  This is
+#     terribly terribly slow.  (Maybe this should be fixed in dgit.)
+#
+#  * Workflow is currently clumsy.  Lots of spurious runes to type.
+#    There's not even a guide.
+#
+#  * new-upstream-v0 has a terrible UI for multiple upstream pieces.
+#    You end up with giant runic command lines.  Does this matter /
+#    One consequence of the lack of richness it can need -f in
+#    fairly sensible situations.
+#
+#  * There should be a good convention for the version number,
+#    and unfinalised or not changelog, after new-upstream.
+#
+#  * Handing of multi-orig dgit new-upstream .dsc imports is known to
+#    be broken.  They may be not recognised, improperly converted, or
+#    their conversion may be unrecognised.
+#
+#  * We need to develop a plausible model that works for derivatives,
+#    who probably want to maintain their stack on top of Debian's.
+#    downstream-rebase-launder-v0 may be a starting point?
+#    maybe the hypothetical git-ffqrebase is part of it too.
+	
+
+# undocumented usages:
+#
+#    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
+
+
 ========================================
 
 Theory for ffq-prev
@@ -121,35 +120,7 @@ We check we are ff from remotes before recording new ffq-prev
 
   ---------- now follows much the same info in different words ----------
 
-1. git-debrebase [-i etc.]
-
-     should:
-        check for ffq-prev
-        if is already a ffq-prev, fine, do no more
-        if not:
-
-        check our origin branch exists and we are ff from it
-        if not fail
-
-        check our other might-be-pushed to branches
-        check we are ff from them
-        if not fail
-
-        set ffq-prev to something which is ff from
-          all above branches
-
-        we use our tip, as discussed above
-        (optionally, can use some other commit which is ff
-         from all of the above, eg one of them)
-
-N. git-debrebase [--noop-ok] record-ffq-prev
-
-     does what is described above
-
-2. git-debrebase [--noop-ok] stitch
-
-    makes pseudomerge with ffq-prev
-    deletes ffq-prev
+Re git-debrebase [--noop-ok] stitch
 
     we will teach dgit to do
        git-debrebase stitch