X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=NOTES.git-debrebase;h=bd6e7151221f67ff54e6100f629c23ce58afaa55;hp=31c0c1c53c168bb31ec2fe3bbad003feedb1937b;hb=52d1506110771ee16b19be4c6b82e06559c9e6f5;hpb=d09d35de46974b3ece2c469f54d898daaa28edf5

diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index 31c0c1c5..bd6e7151 100644
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -1,31 +1,27 @@
-TODO
-   reference docs
-      git-debrebase(1)   command line
-   tutorial
-      dgit-maint-debrebase(7)
-      someone should set branch.<name>.mergeOptions to include --ff-only ?
+# problems / outstanding questions:
+#
+#  * new-upstream has an awkward 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
 
-   clean up remains of README
-
-   arrange for dgit to automatically stitch on push
-
-workflow
-
-  git-debrebase blah [implies start]       strips pseudomerge(s)
-
-  commit / git-debrebase / etc.
-
-  dgit --damp-run push
-      hook: call git-debrebase prep-push   dgit push does not update remote
-      or something, must add patches at least
-
-  commit / git-debrebase / etc.            strips patches
-
-  dgit push
-      hook: call git-debrebase prep-push   dgit push DOES update remote
-
-  commit / git-debrebase / etc.            strips last pm, but arranges
-                                           that remade pm will incorporate it
 
 ========================================
 
@@ -82,66 +78,6 @@ When we do a thing
 
 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
-
-    we will teach dgit to do
-       git-debrebase stitch
-    or some such ?
-
-following parts are not implemented and maybe aren't the
-best subcommand names etc.
-
-3. git-debrebase push
-
-    like git push only does stitch first
-    ??? command line parsing!
-
-4. git-debrebase release
-
-    stiches, finalises changelog, signs tags, pushes everything
-    for the future, when there is some automatic builder
-
-========================================
-
-import from gbp
-
-what about dgit view branch ?
-ideally, would make pseudomerge over dgit view
-would need to check that dgit view is actually dgit view of
-  ond of our ancestors
-failing that first push will need --overwrite
-that is what is currently implemented
-
 ========================================
 
 how to handle divergence and merges (if not detected soon enough)