NOTES.git-debrebase

   1 TODO
   2    reference docs
   3       git-debrebase(1)   command line
   4    tutorial
   5       dgit-maint-debrebase(7)
   6       someone should set branch.<name>.mergeOptions to include --ff-only ?
   7
   8    clean up remains of README
   9
  10    arrange for dgit to automatically stitch on push
  11
  12 workflow
  13
  14   git-debrebase blah [implies start]       strips pseudomerge(s)
  15
  16   commit / git-debrebase / etc.
  17
  18   dgit --damp-run push
  19       hook: call git-debrebase prep-push   dgit push does not update remote
  20       or something, must add patches at least
  21
  22   commit / git-debrebase / etc.            strips patches
  23
  24   dgit push
  25       hook: call git-debrebase prep-push   dgit push DOES update remote
  26
  27   commit / git-debrebase / etc.            strips last pm, but arranges
  28                                            that remade pm will incorporate it
  29
  30 ========================================
  31
  32 Theory for ffq-prev
  33
  34   refs/ffq-prev/REF    relates to refs/REF
  35
  36 When we strip a pm, we need to maybe record it (or something) as the
  37 new start point.
  38
  39 When we do a thing
  40
  41     with no recorded ffq-prev
  42
  43         ffq-prev is our current tip
  44
  45         obviously it is safe to say we will overwrite this
  46         we do check whether there are not-included changes in the remotes
  47         because if the new ffq-prev is not ff from the remotes
  48         the later pushes will fail
  49
  50         this model tends to keep ad-hoc commits made on our
  51         tip branch before we did rebase start, in the
  52         `interchange view' and also in the rebase stack.
  53
  54         also we can explicitly preserve with
  55         git-debrebase stitch
  56
  57         It is always safe to rewind ffq-prev: all
  58         that does is overwrite _less_ stuff.
  59
  60         in any case putative ffq-prev must be ff from remote.
  61         Otherwise when we push it will not be ff, even though we have
  62         made pseudomerge to overwrite ffq-prev.  So if we spot
  63         this, report an error.  see above
  64
  65     with a recorded ffq-prev
  66
  67         we may need to advance ffq-prev, to allow us to generate
  68         future pseudomerges that will be pushable
  69
  70         advancing ffq-prev is dangerous, since it might
  71         effectively cancel the commits that will-ovewrite is advanced
  72         over.
  73
  74         ??? advance it to merge-base( current remote, current tip )
  75         if possible (see above), - ie to current remote, subject
  76         to the condition that that is an ancestor of current tip
  77
  78         currently this is not implemented
  79
  80         better maybe to detect divergence ?  but it is rather late
  81         by then!
  82
  83 We check we are ff from remotes before recording new ffq-prev
  84
  85   ---------- now follows much the same info in different words ----------
  86
  87 N. git-debrebase [--noop-ok] record-ffq-prev
  88
  89      does what is described above
  90
  91 Re git-debrebase [--noop-ok] stitch
  92
  93     we will teach dgit to do
  94        git-debrebase stitch
  95     or some such ?
  96
  97 following parts are not implemented and maybe aren't the
  98 best subcommand names etc.
  99
 100 3. git-debrebase push
 101
 102     like git push only does stitch first
 103     ??? command line parsing!
 104
 105 4. git-debrebase release
 106
 107     stiches, finalises changelog, signs tags, pushes everything
 108     for the future, when there is some automatic builder
 109
 110 ========================================
 111
 112 import from gbp
 113
 114 what about dgit view branch ?
 115 ideally, would make pseudomerge over dgit view
 116 would need to check that dgit view is actually dgit view of
 117   ond of our ancestors
 118 failing that first push will need --overwrite
 119 that is what is currently implemented
 120
 121 ========================================
 122
 123 how to handle divergence and merges (if not detected soon enough)
 124
 125 same problem
 126  if merge, look at branches before merge
 127  generate new combined branch
 128  pseudomerge to overwrite merge
 129
 130 current avaiable strategies:
 131
 132  maybe launder foreign branch
 133
 134  if foreign branch is nmuish, can rebase it onto ours
 135
 136  could merge breakwaters (use analyse to find them)
 137  merge breakwaters (assuming same upstream)
 138  manually construct new patch queue by inspection of
 139   the other two patch queues
 140
 141  instead of manually constructing patch queue, could use
 142   gbp pq export and git merge the patch queues
 143   (ie work with interdiffs)
 144
 145  if upstreams are different and one is ahead
 146   simply treat that as "ours" and
 147   do the work to import changes from the other
 148
 149  if upstreams have diverged, can
 150   resolve somehow to make new upstream
 151   do new-upstream on each branch separately
 152   now reduced to previously "solved" problem
 153
 154  in future, auto patch queue merge algorithm
 155   determine next patch to apply
 156   there are three versions o..O, l..L, r..R
 157   we have already constructed m (previous patch or merged breakwater)
 158   try using vector calculus in the implied cube and compute
 159    multiple ways to check consistency ?
 160
 161 ========================================
 162
 163 For downstreams of Debian, sketch of git-ffqrebase
 164
 165 #    git-ffqrebase start [BASE]
 166 #                # records previous HEAD so it can be overwritten
 167 #                # records base for future git-ffqrebase
 168 #    git-ffqrebase set-base BASE
 169 #    git-ffqrebase <git-rebase options>
 170 #    git-ffqrebase finish
 171 #    git-ffqrebase status [BRANCH]