1 files changed, 0 insertions, 72 deletions
diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index f87718b..bd6e715 100644
@@ -1,45 +1,5 @@
- someone should set branch.<name>.mergeOptions to include --ff-only ?
- 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 ?
- 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
# 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 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
@@ -118,38 +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 ----------
-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)