chiark / gitweb /
git-debrebase: NOTES updates
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Mon, 19 Feb 2018 01:43:57 +0000 (01:43 +0000)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 16 Jun 2018 15:07:00 +0000 (16:07 +0100)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
NOTES.git-debrebase

index b7552b7..f32cf87 100644 (file)
@@ -1,14 +1,13 @@
 TODO
-   reference docs
-      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 ?
 
 
 
@@ -31,11 +30,6 @@ workflow
                                            that remade pm will incorporate it
 
 
-
-# undocumented usages:
-#
-#    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
-
 # problems / outstanding questions:
 #
 #  *  dgit push with a `3.0 (quilt)' package means doing quilt
@@ -43,40 +37,32 @@ workflow
 #     series, one at a time, with dpkg-source --commit.  This is
 #     terribly terribly slow.  (Maybe this should be fixed in dgit.)
 #
-#  * dgit push usually needs to (re)make a pseudomerge.  The "first"
-#    git-debrebase stripped out the previous pseudomerge and could
-#    have remembeed the HEAD.  But it's not quite clear what history
-#    ought to be preserved and what should be discarded.  For now
-#    the user will have to tell dgit --overwrite.
-#
-#    To fix this, do we need a new push hook for 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.
 #
-#    One consequence of the lack of richness it can need --force in
-#    fairly sensible situations and there is no way to tell it what
-#    you are really trying to do, other than just --force.  There
-#    should be an interface with some default branch names.
-#
-#  * There should be a standard convention for the version number,
+#  * 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.
 #
-#  * Docs need writing and updating.  Even README.git-debrebase
-#    describes a design but may not reflect the implementation.
-#
 #  * 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