+TODO
+ recognise anchor merge by annotation, not just by structure
+
+ 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
+
+# git-ffqrebase start [BASE]
+# # records previous HEAD so it can be overwritten
+# # records base for future git-ffqrebase
+# git-ffqrebase set-base BASE
+# git-ffqrebase <git-rebase options>
+# git-ffqrebase finish
+# git-ffqrebase status [BRANCH]
+#
+# refs/ffq-prev/REF relates to refs/REF
+#
+# git-debrebase without start, if already started, is willing
+# to strip pseudomerges provided that they overwrite exactly
+# the previous HEAD
+# xxxx is this right ? what matters is have we pushed
+# I think in fact the right answer is:
+# git-debrebase always strips out pseudomerges from its branch
+# a pseudomerge is put in at the time we want to push
+# at that time, we make a pseudomerge of the remote tracking
+# branch (if raw git) or the dgit view (if dgit)
+# for raw git git-ffqrebase, do want preciseley to record
+# value of remote tracking branch or our branch, on start, so we
+# overwrite only things we intend to
+# the previous pseudomerge check for tags and remote branches ?
+
+
+=========
+
+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
git-debrebase blah [implies start] strips pseudomerge(s)
this is OK). Or maybe to the last pseudomerge on the current tip,
so that the overall result will be series of pseudomerges.
+========================================
+
+So, pm handling specifics:
+
+strategy is to avoid making needless pseudomerges
+pseudomerges that exist will be preserved
+(by being included in will-overwrite)
+
+This is good because the presence of a pseudomerge means we know we
+want to keep it; and that allows explicit control over history detail
+level.
+
+It does mean we must avoid making the pseudomerges unnecessarily.
+They should be made just before (ideally, part of) dgit push.
+
+1. git-debrebase [-i etc.]
+
+ should:
+ check for will-overwrite
+ if is already a will-overwrite, 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 will-overwrite 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 will-overwrite
+ deletes will-overwrite
+
+ we will teach dgit to do
+ git-debrebase stitch
+
+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
+
+will-overwrite 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
+
+========================================
+
+divergence, merges:
+
+same problem
+ if merge, look at branches before merge
+ generate new combined branch
+ pseudomerge to overwrite merge
+
+current avaiable strategies:
+
+ maybe launder foreign branch
+
+ if foreign branch is nmuish, can rebase it onto ours
+
+ could merge breakwaters (use analyse to find them)
+ merge breakwaters (assuming same upstream)
+ manually construct new patch queue by inspection of
+ the other two patch queues
+
+ instead of manually constructing patch queue, could use
+ gbp pq export and git merge the patch queues
+ (ie work with interdiffs)
+
+ if upstreams are different and one is ahead
+ simply treat that as "ours" and
+ do the work to import changes from the other
+
+ if upstreams have diverged, can
+ resolve somehow to make new upstream
+ do new-upstream on each branch separately
+ now reduced to previously "solved" problem
+
+ in future, auto patch queue merge algorithm
+ determine next patch to apply
+ there are three versions o..O, l..L, r..R
+ we have already constructed m (previous patch or merged breakwater)
+ try using vector calculus in the implied cube and compute
+ multiple ways to check consistency ?
~ianmdlvl / dgit.git / blobdiff