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 ?
- clean up remains of NOTES and README
-
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
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
+ 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.
---------- 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
+ or some such ?
+
+following parts are not implemented and maybe aren't the
+best subcommand names etc.
3. git-debrebase push
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
-[ 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
+that is what is currently implemented
========================================
========================================
+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
~ianmdlvl / dgit.git / blobdiff