-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
-
-
-
-
-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
-
-
-
-# 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.
+# * 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.
#
-# 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
We check we are ff from remotes before recording new ffq-prev
- ---------- now follows much the same info in different words ----------
-
-Re git-debrebase [--noop-ok] 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
-
- 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)
~ianmdlvl / dgit.git / blobdiff