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