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 special commit tags
  33 overall format
  34   [git-debrebase[ COMMIT-TYPE [ ARGS...]]: PROSE, MORE PROSE]
  35
  36 [git-debrebase: split mixed commit, debian part]
  37 [git-debrebase: split mixed commit, upstream-part]
  38 [git-debrebase: convert dgit import, debian changes]
  39 [git-debrebase breakwater: convert dgit import, upstream changes]
  40
  41 [git-debrebase upstream-combine . PIECE[ PIECE...]: new upstream]
  42 [git-debrebase breakwater: new upstream NEW-UPSTREAM-VERSION, merge]
  43 [git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog]
  44
  45 [git-debrebase: gbp2debrebase, drop patches]
  46 [git-debrebase breakwater: declare upstream]
  47
  48 m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
  49
  50 =========
  51
  52 workflow
  53
  54   git-debrebase blah [implies start]       strips pseudomerge(s)
  55
  56   commit / git-debrebase / etc.
  57
  58   dgit --damp-run push
  59       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
  60                                            dgit push does not update remote
  61
  62   commit / git-debrebase / etc.            strips pm(s) including last one
  63
  64   dgit push
  65       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
  66                                            dgit push DOES update remote
  67
  68   commit / git-debrebase / etc.            strips last pm, but arranges
  69                                            that remade pm will incorporate it
  70
  71 Aha!
  72
  73 When we strip a pm, we need to maybe record it (or something) as the
  74 new start point.
  75
  76 We do this if the pm is contained within the output branch.
  77
  78 Actually this is not special to PMs.
  79
  80 We need to record a new to-be-overwritten commit
  81    merge-base( our branch tip, relevant remote )
  82
  83 If this is not a descendant of the relevant remote, then we are going
  84 to have a problem when we push so issue a warning or fail.
  85
  86
  87
  88 How about
  89
  90   git-debrebase start or git-debrebase [continue]
  91
  92     with no recorded will-overwrite
  93
  94         putative will-overwrite is
  95             one model:
  96                 our current tip
  97                 obviously it is safe to say we will overwrite this
  98                 we do not need to worry about whether this will
  99                     overwrite not-included changes in the remote
 100                     because either the will-overwrite is not
 101                     ff from the remote (in which case later failure,
 102                     see below); or the will-overwrite _is_ ff
 103                     from the remote ie our tip is later than the
 104                     remote and includes all of its changes
 105
 106                 this model tends to keep ad-hoc commits made on our
 107                 tip branch before we did rebase start, in the
 108                 `interchange view' and also in the rebase stack.
 109
 110             other model:
 111                 merge-base( current remote, current tip )
 112
 113                 it is safe to overwrite current tip, by the
 114                 argument above
 115
 116                 it is always safe to rewind will-overwrite: all
 117                 that does is overwrite _less_ stuff
 118
 119                 this is the earliest overwrite we can make that
 120                     will be pushable to the remote
 121
 122                 in practical terms this can only be ff from the
 123                 current remote if it is equal to the current remote;
 124                 so what we are actually checking below is that our tip
 125                 is ff from the remote.  This ought to be true before
 126                 the first of our rebases.
 127
 128                 this model tends to rewind and rebase ad-hoc commits
 129                 made on our tip branch before we did rebase start,
 130                 this is better
 131
 132         in any case putative will-overwrite must be ff from remote.
 133         Otherwise when we push it will not be ff, even though we have
 134         made pseudomerge to overwrite will-overwrite.  So if we spot
 135         this, report an error.
 136
 137     with a recorded will-overwrite
 138
 139         we may need to advance will-overwrite, to allow us to generate
 140         future pseudomerges that will be pushable
 141
 142         advancing will-overwrite is dangerous, since it might
 143         effectively cancel the commits that will-ovewrite is advanced
 144         over.
 145
 146         we advance it to merge-base( current remote, current tip )
 147         if possible (see above), - ie to current remote, subject
 148         to the condition that that is an ancestor of current tip
 149
 150 In each case we can strip pseudomerges freely, as needed.  We do not
 151 want to record what pseudomerges we strip, because whether we need to
 152 keep them depends (only) on whether they have been pushed.
 153
 154 Is that actually true ?  What if the user actually _wanted_ to keep
 155 the pseudomerge despite not having pushed it ?
 156
 157 In that case we need to advance will-overwrite past it.  We could
 158 provide an explicit command to do this: it would advance
 159 will-overwrite to the current tip (see rules above, which show that
 160 this is OK).  Or maybe to the last pseudomerge on the current tip,
 161 so that the overall result will be series of pseudomerges.
 162
 163 ========================================
 164
 165 import from gbp
 166
 167  inputs:
 168    current HEAD (patches-unapplied),
 169      this is going to be the base of the old breakwater
 170    nominated upstream
 171
 172  checks:
 173    HEAD:<upstream> = upstream:<upstream>
 174    upstream..HEAD:<upstream> is empty (overrideable)
 175    upstremm:debian is empty (overrideable)
 176
 177  procedure:
 178    construct
 179      run gbp pq import to generate pq branch
 180      new breakwater is
 181        old HEAD
 182        commit to remove d/patches
 183        breakwater pseudomerge with upstream
 184        "rebase" of pq branch, each commit with d/patches stripped
 185
 186 what about dgit view branch ?
 187 ideally, would make pseudomerge over dgit view
 188 would need to check that dgit view is actually dgit view of
 189   ond of our ancestors
 190 failing that first push will need --overwrite