git-debrebase: Provide conclude subcommand

[dgit.git] / NOTES.git-debrebase

diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index 97038733dca16ae3337a2a29c1e7a41be0be21ab..f32cf87ec78e894d474bd149e4c7d3603fd9aaad 100644 (file)
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -1,54 +1,15 @@
 TODO
 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 ?
 
    tutorial
       dgit-maint-debrebase(7)
       someone should set branch.<name>.mergeOptions to include --ff-only ?
 

-   clean up remains of NOTES and README
-

    arrange for dgit to automatically stitch on push
    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 ?

 
 

-========================================
-
-#  refs/ffq-prev/REF    relates to refs/REF
-
-=======================================
-
-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
 
 
 workflow
 


@@ -68,10 +29,46 @@ workflow
   commit / git-debrebase / etc.            strips last pm, but arranges
                                            that remade pm will incorporate it
 
   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
 
 ========================================
 
 Theory for ffq-prev
 

+  refs/ffq-prev/REF    relates to refs/REF
+

 When we strip a pm, we need to maybe record it (or something) as the
 new start point.
 
 When we strip a pm, we need to maybe record it (or something) as the
 new start point.
 


@@ -123,38 +120,14 @@ We check we are ff from remotes before recording new ffq-prev
 
   ---------- now follows much the same info in different words ----------
 
 
   ---------- 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
 
     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
 
 
 3. git-debrebase push
 


@@ -166,41 +139,16 @@ N. git-debrebase [--noop-ok] record-ffq-prev
     stiches, finalises changelog, signs tags, pushes everything
     for the future, when there is some automatic builder
 
     stiches, finalises changelog, signs tags, pushes everything
     for the future, when there is some automatic builder
 

-ffq-prev for each ref
-    refs/heads/FOO
-is
-    refs/ffq-prev/FOO
-

 ========================================
 
 import from gbp
 
 ========================================
 
 import from gbp
 

-[ all this is done now:
- inputs:
-   current HEAD (patches-unapplied),
-     this is going to be the base of the old breakwater
-   nominated upstream
-
- checks:
-   HEAD:<upstream> = upstream:<upstream>
-   upstream..HEAD:<upstream> is empty (overrideable)
-   upstremm:debian is empty (overrideable)
-
- procedure:
-   construct
-     run gbp pq import to generate pq branch
-     new breakwater is
-       old HEAD
-       commit to remove d/patches
-       anchor merge with upstream
-       "rebase" of pq branch, each commit with d/patches stripped
-]
-

 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
 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

 
 ========================================
 
 
 ========================================
 


@@ -244,6 +192,8 @@ current avaiable strategies:
 
 ========================================
 
 
 ========================================
 

+For downstreams of Debian, sketch of git-ffqrebase
+

 #    git-ffqrebase start [BASE]
 #                # records previous HEAD so it can be overwritten
 #                # records base for future git-ffqrebase
 #    git-ffqrebase start [BASE]
 #                # records previous HEAD so it can be overwritten
 #                # records base for future git-ffqrebase