chiark / gitweb /
git-debrebase: move some todo/notes to NOTES
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Mon, 19 Feb 2018 01:39:50 +0000 (01:39 +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
git-debrebase

index 7b9a9b19f39c4b7b3928991ae932d0c3fe0586c9..b7552b7024af19bf969af7c33152b1e9de60baab 100644 (file)
@@ -9,6 +9,9 @@ TODO
 
    arrange for dgit to automatically stitch on push
 
+
+
+
 workflow
 
   git-debrebase blah [implies start]       strips pseudomerge(s)
@@ -27,6 +30,53 @@ workflow
   commit / git-debrebase / etc.            strips last pm, but arranges
                                            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
+#     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.)
+#
+#  * 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 --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,
+#    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?
+       
+
 ========================================
 
 Theory for ffq-prev
index 75a8f51a96b1638bd6d4847c0b6f721bd113a51a..9d87e76760ce866c717e0962fdec78868652bc4f 100755 (executable)
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-
-# undocumented usages:
-#
-#    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
-
-# 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.)
-#
-#  * 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.
-#
-#  * There are no tests.
-#
-#  * new-upstream-v0 has a terrible UI.  You end up with giant
-#    runic command lines.
-#
-#    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,
-#    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?
-
 use strict;
 
 use Debian::Dgit qw(:DEFAULT :playground);