X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=NOTES.git-debrebase;h=1cfa070b2d2046c3705395687e13825a6524c9ce;hp=8aed2ff28887803b6481e75e4a2997ca59221a65;hb=c386ae2688431a622f9d41b3668755420fcbed39;hpb=f8ea491fa27e80e4f2fac287d01071b8b27861cc

diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index 8aed2ff2..1cfa070b 100644
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -1,5 +1,16 @@
+TODO
+   more tests, see "todo" in gdr-editw
+   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
@@ -40,8 +51,11 @@ overall format
 [git-debrebase breakwater: new upstream NEW-UPSTREAM-VERSION, merge]
 [git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog]
 
-[git-debrebase: gbp2debrebase, drop patches]
+[git-debrebase convert-from-gbp: drop patches]
 [git-debrebase breakwater: declare upstream]
+[git-debrebase pseudomerge: stitch]
+
+[git-debrebase convert-to-gbp: commit patches]
 
 m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
 
@@ -264,5 +278,42 @@ would need to check that dgit view is actually dgit view of
   ond of our ancestors
 failing that first push will need --overwrite
 
-should this be called import or gbp2debrebase as it is now ?
-gbp uses "import" oddly but I'm tempted to use it normally here.
+========================================
+
+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 ?