TODO
reference docs
- git-debrebase(5) data model
git-debrebase(1) command line
tutorial
dgit-maint-debrebase(7)
arrange for dgit to automatically stitch on push
+
+
+
workflow
git-debrebase blah [implies start] strips pseudomerge(s)
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
---------- 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