NOTES.git-debrebase

   1 # problems / outstanding questions:
   2 #
   3 #  * new-upstream has an awkward UI for multiple upstream pieces.
   4 #    You end up with giant runic command lines.  Does this matter /
   5 #    One consequence of the lack of richness it can need -f in
   6 #    fairly sensible situations.
   7 #
   8 #  * There should be a good convention for the version number,
   9 #    and unfinalised or not changelog, after new-upstream.
  10 #
  11 #  * Handing of multi-orig dgit new-upstream .dsc imports is known to
  12 #    be broken.  They may be not recognised, improperly converted, or
  13 #    their conversion may be unrecognised.
  14 #
  15 #  * We need to develop a plausible model that works for derivatives,
  16 #    who probably want to maintain their stack on top of Debian's.
  17 #    downstream-rebase-launder-v0 may be a starting point?
  18 #    maybe the hypothetical git-ffqrebase is part of it too.
  19
  20
  21 # undocumented usages:
  22 #
  23 #    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
  24
  25
  26 ========================================
  27
  28 Theory for ffq-prev
  29
  30   refs/ffq-prev/REF    relates to refs/REF
  31
  32 When we strip a pm, we need to maybe record it (or something) as the
  33 new start point.
  34
  35 When we do a thing
  36
  37     with no recorded ffq-prev
  38
  39         ffq-prev is our current tip
  40
  41         obviously it is safe to say we will overwrite this
  42         we do check whether there are not-included changes in the remotes
  43         because if the new ffq-prev is not ff from the remotes
  44         the later pushes will fail
  45
  46         this model tends to keep ad-hoc commits made on our
  47         tip branch before we did rebase start, in the
  48         `interchange view' and also in the rebase stack.
  49
  50         also we can explicitly preserve with
  51         git-debrebase stitch
  52
  53         It is always safe to rewind ffq-prev: all
  54         that does is overwrite _less_ stuff.
  55
  56         in any case putative ffq-prev must be ff from remote.
  57         Otherwise when we push it will not be ff, even though we have
  58         made pseudomerge to overwrite ffq-prev.  So if we spot
  59         this, report an error.  see above
  60
  61     with a recorded ffq-prev
  62
  63         we may need to advance ffq-prev, to allow us to generate
  64         future pseudomerges that will be pushable
  65
  66         advancing ffq-prev is dangerous, since it might
  67         effectively cancel the commits that will-ovewrite is advanced
  68         over.
  69
  70         ??? advance it to merge-base( current remote, current tip )
  71         if possible (see above), - ie to current remote, subject
  72         to the condition that that is an ancestor of current tip
  73
  74         currently this is not implemented
  75
  76         better maybe to detect divergence ?  but it is rather late
  77         by then!
  78
  79 We check we are ff from remotes before recording new ffq-prev
  80
  81 ========================================
  82
  83 how to handle divergence and merges (if not detected soon enough)
  84
  85 same problem
  86  if merge, look at branches before merge
  87  generate new combined branch
  88  pseudomerge to overwrite merge
  89
  90 current avaiable strategies:
  91
  92  maybe launder foreign branch
  93
  94  if foreign branch is nmuish, can rebase it onto ours
  95
  96  could merge breakwaters (use analyse to find them)
  97  merge breakwaters (assuming same upstream)
  98  manually construct new patch queue by inspection of
  99   the other two patch queues
 100
 101  instead of manually constructing patch queue, could use
 102   gbp pq export and git merge the patch queues
 103   (ie work with interdiffs)
 104
 105  if upstreams are different and one is ahead
 106   simply treat that as "ours" and
 107   do the work to import changes from the other
 108
 109  if upstreams have diverged, can
 110   resolve somehow to make new upstream
 111   do new-upstream on each branch separately
 112   now reduced to previously "solved" problem
 113
 114  in future, auto patch queue merge algorithm
 115   determine next patch to apply
 116   there are three versions o..O, l..L, r..R
 117   we have already constructed m (previous patch or merged breakwater)
 118   try using vector calculus in the implied cube and compute
 119    multiple ways to check consistency ?
 120
 121 ========================================
 122
 123 For downstreams of Debian, sketch of git-ffqrebase
 124
 125 #    git-ffqrebase start [BASE]
 126 #                # records previous HEAD so it can be overwritten
 127 #                # records base for future git-ffqrebase
 128 #    git-ffqrebase set-base BASE
 129 #    git-ffqrebase <git-rebase options>
 130 #    git-ffqrebase finish
 131 #    git-ffqrebase status [BRANCH]