NOTES.git-debrebase

   1 TODO
   2    tutorial
   3       dgit-maint-debrebase(7)
   4       someone should set branch.<name>.mergeOptions to include --ff-only ?
   5
   6    arrange for dgit to automatically stitch on push
   7      dgit push usually needs to (re)make a pseudomerge.  The "first"
   8      git-debrebase stripped out the previous pseudomerge and could
   9      remembeed the old HEAD.  But the user has to manually stitch it.
  10      To fix this, do we need a new push hook for dgit ?
  11
  12
  13
  14 workflow
  15
  16   git-debrebase blah [implies start]       strips pseudomerge(s)
  17
  18   commit / git-debrebase / etc.
  19
  20   dgit --damp-run push
  21       hook: call git-debrebase prep-push   dgit push does not update remote
  22       or something, must add patches at least
  23
  24   commit / git-debrebase / etc.            strips patches
  25
  26   dgit push
  27       hook: call git-debrebase prep-push   dgit push DOES update remote
  28
  29   commit / git-debrebase / etc.            strips last pm, but arranges
  30                                            that remade pm will incorporate it
  31
  32
  33 # problems / outstanding questions:
  34 #
  35 #  *  dgit push with a `3.0 (quilt)' package means doing quilt
  36 #     fixup.  Usually this involves recommitting the whole patch
  37 #     series, one at a time, with dpkg-source --commit.  This is
  38 #     terribly terribly slow.  (Maybe this should be fixed in dgit.)
  39 #
  40 #  * Workflow is currently clumsy.  Lots of spurious runes to type.
  41 #    There's not even a guide.
  42 #
  43 #  * new-upstream-v0 has a terrible UI for multiple upstream pieces.
  44 #    You end up with giant runic command lines.  Does this matter /
  45 #    One consequence of the lack of richness it can need -f in
  46 #    fairly sensible situations.
  47 #
  48 #  * There should be a good convention for the version number,
  49 #    and unfinalised or not changelog, after new-upstream.
  50 #
  51 #  * Handing of multi-orig dgit new-upstream .dsc imports is known to
  52 #    be broken.  They may be not recognised, improperly converted, or
  53 #    their conversion may be unrecognised.
  54 #
  55 #  * We need to develop a plausible model that works for derivatives,
  56 #    who probably want to maintain their stack on top of Debian's.
  57 #    downstream-rebase-launder-v0 may be a starting point?
  58 #    maybe the hypothetical git-ffqrebase is part of it too.
  59
  60
  61 # undocumented usages:
  62 #
  63 #    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
  64
  65
  66 ========================================
  67
  68 Theory for ffq-prev
  69
  70   refs/ffq-prev/REF    relates to refs/REF
  71
  72 When we strip a pm, we need to maybe record it (or something) as the
  73 new start point.
  74
  75 When we do a thing
  76
  77     with no recorded ffq-prev
  78
  79         ffq-prev is our current tip
  80
  81         obviously it is safe to say we will overwrite this
  82         we do check whether there are not-included changes in the remotes
  83         because if the new ffq-prev is not ff from the remotes
  84         the later pushes will fail
  85
  86         this model tends to keep ad-hoc commits made on our
  87         tip branch before we did rebase start, in the
  88         `interchange view' and also in the rebase stack.
  89
  90         also we can explicitly preserve with
  91         git-debrebase stitch
  92
  93         It is always safe to rewind ffq-prev: all
  94         that does is overwrite _less_ stuff.
  95
  96         in any case putative ffq-prev must be ff from remote.
  97         Otherwise when we push it will not be ff, even though we have
  98         made pseudomerge to overwrite ffq-prev.  So if we spot
  99         this, report an error.  see above
 100
 101     with a recorded ffq-prev
 102
 103         we may need to advance ffq-prev, to allow us to generate
 104         future pseudomerges that will be pushable
 105
 106         advancing ffq-prev is dangerous, since it might
 107         effectively cancel the commits that will-ovewrite is advanced
 108         over.
 109
 110         ??? advance it to merge-base( current remote, current tip )
 111         if possible (see above), - ie to current remote, subject
 112         to the condition that that is an ancestor of current tip
 113
 114         currently this is not implemented
 115
 116         better maybe to detect divergence ?  but it is rather late
 117         by then!
 118
 119 We check we are ff from remotes before recording new ffq-prev
 120
 121   ---------- now follows much the same info in different words ----------
 122
 123 Re git-debrebase [--noop-ok] stitch
 124
 125     we will teach dgit to do
 126        git-debrebase stitch
 127     or some such ?
 128
 129 following parts are not implemented and maybe aren't the
 130 best subcommand names etc.
 131
 132 3. git-debrebase push
 133
 134     like git push only does stitch first
 135     ??? command line parsing!
 136
 137 4. git-debrebase release
 138
 139     stiches, finalises changelog, signs tags, pushes everything
 140     for the future, when there is some automatic builder
 141
 142 ========================================
 143
 144 import from gbp
 145
 146 what about dgit view branch ?
 147 ideally, would make pseudomerge over dgit view
 148 would need to check that dgit view is actually dgit view of
 149   ond of our ancestors
 150 failing that first push will need --overwrite
 151 that is what is currently implemented
 152
 153 ========================================
 154
 155 how to handle divergence and merges (if not detected soon enough)
 156
 157 same problem
 158  if merge, look at branches before merge
 159  generate new combined branch
 160  pseudomerge to overwrite merge
 161
 162 current avaiable strategies:
 163
 164  maybe launder foreign branch
 165
 166  if foreign branch is nmuish, can rebase it onto ours
 167
 168  could merge breakwaters (use analyse to find them)
 169  merge breakwaters (assuming same upstream)
 170  manually construct new patch queue by inspection of
 171   the other two patch queues
 172
 173  instead of manually constructing patch queue, could use
 174   gbp pq export and git merge the patch queues
 175   (ie work with interdiffs)
 176
 177  if upstreams are different and one is ahead
 178   simply treat that as "ours" and
 179   do the work to import changes from the other
 180
 181  if upstreams have diverged, can
 182   resolve somehow to make new upstream
 183   do new-upstream on each branch separately
 184   now reduced to previously "solved" problem
 185
 186  in future, auto patch queue merge algorithm
 187   determine next patch to apply
 188   there are three versions o..O, l..L, r..R
 189   we have already constructed m (previous patch or merged breakwater)
 190   try using vector calculus in the implied cube and compute
 191    multiple ways to check consistency ?
 192
 193 ========================================
 194
 195 For downstreams of Debian, sketch of git-ffqrebase
 196
 197 #    git-ffqrebase start [BASE]
 198 #                # records previous HEAD so it can be overwritten
 199 #                # records base for future git-ffqrebase
 200 #    git-ffqrebase set-base BASE
 201 #    git-ffqrebase <git-rebase options>
 202 #    git-ffqrebase finish
 203 #    git-ffqrebase status [BRANCH]