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 Re git-debrebase [--noop-ok] stitch
  88
  89     we will teach dgit to do
  90        git-debrebase stitch
  91     or some such ?
  92
  93 following parts are not implemented and maybe aren't the
  94 best subcommand names etc.
  95
  96 3. git-debrebase push
  97
  98     like git push only does stitch first
  99     ??? command line parsing!
 100
 101 4. git-debrebase release
 102
 103     stiches, finalises changelog, signs tags, pushes everything
 104     for the future, when there is some automatic builder
 105
 106 ========================================
 107
 108 import from gbp
 109
 110 what about dgit view branch ?
 111 ideally, would make pseudomerge over dgit view
 112 would need to check that dgit view is actually dgit view of
 113   ond of our ancestors
 114 failing that first push will need --overwrite
 115 that is what is currently implemented
 116
 117 ========================================
 118
 119 how to handle divergence and merges (if not detected soon enough)
 120
 121 same problem
 122  if merge, look at branches before merge
 123  generate new combined branch
 124  pseudomerge to overwrite merge
 125
 126 current avaiable strategies:
 127
 128  maybe launder foreign branch
 129
 130  if foreign branch is nmuish, can rebase it onto ours
 131
 132  could merge breakwaters (use analyse to find them)
 133  merge breakwaters (assuming same upstream)
 134  manually construct new patch queue by inspection of
 135   the other two patch queues
 136
 137  instead of manually constructing patch queue, could use
 138   gbp pq export and git merge the patch queues
 139   (ie work with interdiffs)
 140
 141  if upstreams are different and one is ahead
 142   simply treat that as "ours" and
 143   do the work to import changes from the other
 144
 145  if upstreams have diverged, can
 146   resolve somehow to make new upstream
 147   do new-upstream on each branch separately
 148   now reduced to previously "solved" problem
 149
 150  in future, auto patch queue merge algorithm
 151   determine next patch to apply
 152   there are three versions o..O, l..L, r..R
 153   we have already constructed m (previous patch or merged breakwater)
 154   try using vector calculus in the implied cube and compute
 155    multiple ways to check consistency ?
 156
 157 ========================================
 158
 159 For downstreams of Debian, sketch of git-ffqrebase
 160
 161 #    git-ffqrebase start [BASE]
 162 #                # records previous HEAD so it can be overwritten
 163 #                # records base for future git-ffqrebase
 164 #    git-ffqrebase set-base BASE
 165 #    git-ffqrebase <git-rebase options>
 166 #    git-ffqrebase finish
 167 #    git-ffqrebase status [BRANCH]