NOTES.git-debrebase

   1
   2 #
   3 #    git-ffqrebase start [BASE]
   4 #                # records previous HEAD so it can be overwritten
   5 #                # records base for future git-ffqrebase
   6 #    git-ffqrebase set-base BASE
   7 #    git-ffqrebase <git-rebase options>
   8 #    git-ffqrebase finish
   9 #    git-ffqrebase status [BRANCH]
  10 #
  11 #  refs/ffqrebase-prev/BRANCH    BRANCH may be refs/...; if not it means
  12 #  refs/ffqrebase-base/BRANCH      refs/heads/BRANCH
  13 #                               zero, one, or both of these may exist
  14 #
  15 # git-debrebase without start, if already started, is willing
  16 # to strip pseudomerges provided that they overwrite exactly
  17 # the previous HEAD
  18 #  xxxx is this right ?  what matters is have we pushed
  19 #    I think in fact the right answer is:
  20 #       git-debrebase always strips out pseudomerges from its branch
  21 #       a pseudomerge is put in at the time we want to push
  22 #       at that time, we make a pseudomerge of the remote tracking
  23 #           branch (if raw git) or the dgit view (if dgit)
  24 #       for raw git git-ffqrebase, do want preciseley to record
  25 #           value of remote tracking branch or our branch, on start, so we
  26 #           overwrite only things we intend to
  27 #  the previous pseudomerge    check for tags and remote branches ?
  28
  29
  30 =========
  31
  32 workflow
  33
  34   git-debrebase blah [implies start]       strips pseudomerge(s)
  35
  36   commit / git-debrebase / etc.
  37
  38   dgit --damp-run push
  39       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
  40                                            dgit push does not update remote
  41
  42   commit / git-debrebase / etc.            strips pm(s) including last one
  43
  44   dgit push
  45       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
  46                                            dgit push DOES update remote
  47
  48   commit / git-debrebase / etc.            strips last pm, but arranges
  49                                            that remade pm will incorporate it
  50
  51 Aha!
  52
  53 When we strip a pm, we need to maybe record it (or something) as the
  54 new start point.
  55
  56 We do this if the pm is contained within the output branch.
  57
  58 Actually this is not special to PMs.
  59
  60 We need to record a new to-be-overwritten commit
  61    merge-base( our branch tip, relevant remote )
  62
  63 If this is not a descendant of the relevant remote, then we are going
  64 to have a problem when we push so issue a warning or fail.
  65
  66
  67
  68 How about
  69
  70   git-debrebase start or git-debrebase [continue]
  71
  72     with no recorded will-overwrite
  73
  74         putative will-overwrite is
  75             one model:
  76                 our current tip
  77                 obviously it is safe to say we will overwrite this
  78                 we do not need to worry about whether this will
  79                     overwrite not-included changes in the remote
  80                     because either the will-overwrite is not
  81                     ff from the remote (in which case later failure,
  82                     see below); or the will-overwrite _is_ ff
  83                     from the remote ie our tip is later than the
  84                     remote and includes all of its changes
  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             other model:
  91                 merge-base( current remote, current tip )
  92
  93                 it is safe to overwrite current tip, by the
  94                 argument above
  95
  96                 it is always safe to rewind will-overwrite: all
  97                 that does is overwrite _less_ stuff
  98
  99                 this is the earliest overwrite we can make that
 100                     will be pushable to the remote
 101
 102                 in practical terms this can only be ff from the
 103                 current remote if it is equal to the current remote;
 104                 so what we are actually checking below is that our tip
 105                 is ff from the remote.  This ought to be true before
 106                 the first of our rebases.
 107
 108                 this model tends to rewind and rebase ad-hoc commits
 109                 made on our tip branch before we did rebase start,
 110                 this is better
 111
 112         in any case putative will-overwrite must be ff from remote.
 113         Otherwise when we push it will not be ff, even though we have
 114         made pseudomerge to overwrite will-overwrite.  So if we spot
 115         this, report an error.
 116
 117     with a recorded will-overwrite
 118
 119         we may need to advance will-overwrite, to allow us to generate
 120         future pseudomerges that will be pushable
 121
 122         advancing will-overwrite is dangerous, since it might
 123         effectively cancel the commits that will-ovewrite is advanced
 124         over.
 125
 126         we advance it to merge-base( current remote, current tip )
 127         if possible (see above), - ie to current remote, subject
 128         to the condition that that is an ancestor of current tip
 129
 130 In each case we can strip pseudomerges freely, as needed.  We do not
 131 want to record what pseudomerges we strip, because whether we need to
 132 keep them depends (only) on whether they have been pushed.
 133
 134 Is that actually true ?  What if the user actually _wanted_ to keep
 135 the pseudomerge despite not having pushed it ?
 136
 137 In that case we need to advance will-overwrite past it.  We could
 138 provide an explicit command to do this: it would advance
 139 will-overwrite to the current tip (see rules above, which show that
 140 this is OK).  Or maybe to the last pseudomerge on the current tip,
 141 so that the overall result will be series of pseudomerges.
 142
 143 ========================================
 144
 145 import from gbp
 146
 147  inputs:
 148    current HEAD (patches-unapplied),
 149      this is going to be the base of the old breakwater
 150    nominated upstream
 151
 152  checks:
 153    HEAD:<upstream> = upstream:<upstream>
 154    upstream..HEAD:<upstream> is empty (overrideable)
 155    upstremm:debian is empty (overrideable)
 156
 157  procedure:
 158    construct
 159      run gbp pq import to generate pq branch
 160      new breakwater is
 161        old HEAD
 162        commit to remove d/patches
 163        breakwater pseudomerge with upstream
 164        "rebase" of pq branch, each commit with d/patches stripped
 165
 166 what about dgit view branch ?
 167 ideally, would make pseudomerge over dgit view
 168 would need to check that dgit view is actually dgit view of
 169   ond of our ancestors
 170 failing that first push will need --overwrite