NOTES.git-debrebase-pseudomergehandling

   1 workflow
   2
   3   git-debrebase blah [implies start]       strips pseudomerge(s)
   4
   5   commit / git-debrebase / etc.
   6
   7   dgit --damp-run push
   8       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
   9                                            dgit push does not update remote
  10
  11   commit / git-debrebase / etc.            strips pm(s) including last one
  12
  13   dgit push
  14       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
  15                                            dgit push DOES update remote
  16
  17   commit / git-debrebase / etc.            strips last pm, but arranges
  18                                            that remade pm will incorporate it
  19
  20 Aha!
  21
  22 When we strip a pm, we need to maybe record it (or something) as the
  23 new start point.
  24
  25 We do this if the pm is contained within the output branch.
  26
  27 Actually this is not special to PMs.
  28
  29 We need to record a new to-be-overwritten commit
  30    merge-base( our branch tip, relevant remote )
  31
  32 If this is not a descendant of the relevant remote, then we are going
  33 to have a problem when we push so issue a warning or fail.
  34
  35
  36
  37 How about
  38
  39   git-debrebase start or git-debrebase [continue]
  40
  41     with no recorded will-overwrite
  42
  43         putative will-overwrite is
  44             one model:
  45                 our current tip
  46                 obviously it is safe to say we will overwrite this
  47                 we do not need to worry about whether this will
  48                     overwrite not-included changes in the remote
  49                     because either the will-overwrite is not
  50                     ff from the remote (in which case later failure,
  51                     see below); or the will-overwrite _is_ ff
  52                     from the remote ie our tip is later than the
  53                     remote and includes all of its changes
  54
  55                 this model tends to keep ad-hoc commits made on our
  56                 tip branch before we did rebase start, in the
  57                 `interchange view' and also in the rebase stack.
  58
  59             other model:
  60                 merge-base( current remote, current tip )
  61
  62                 it is safe to overwrite current tip, by the
  63                 argument above
  64
  65                 it is always safe to rewind will-overwrite: all
  66                 that does is overwrite _less_ stuff
  67
  68                 this is the earliest overwrite we can make that
  69                     will be pushable to the remote
  70
  71                 in practical terms this can only be ff from the
  72                 current remote if it is equal to the current remote;
  73                 so what we are actually checking below is that our tip
  74                 is ff from the remote.  This ought to be true before
  75                 the first of our rebases.
  76
  77                 this model tends to rewind and rebase ad-hoc commits
  78                 made on our tip branch before we did rebase start,
  79                 this is better
  80
  81         in any case putative will-overwrite must be ff from remote.
  82         Otherwise when we push it will not be ff, even though we have
  83         made pseudomerge to overwrite will-overwrite.  So if we spot
  84         this, report an error.
  85
  86     with a recorded will-overwrite
  87
  88         we may need to advance will-overwrite, to allow us to generate
  89         future pseudomerges that will be pushable
  90
  91         advancing will-overwrite is dangerous, since it might
  92         effectively cancel the commits that will-ovewrite is advanced
  93         over.
  94
  95         we advance it to merge-base( current remote, current tip )
  96         if possible (see above), - ie to current remote, subject
  97         to the condition that that is an ancestor of current tip
  98
  99 In each case we can strip pseudomerges freely, as needed.  We do not
 100 want to record what pseudomerges we strip, because whether we need to
 101 keep them depends (only) on whether they have been pushed.
 102
 103 Is that actually true ?  What if the user actually _wanted_ to keep
 104 the pseudomerge despite not having pushed it ?
 105
 106 In that case we need to advance will-overwrite past it.  We could
 107 provide an explicit command to do this: it would advance
 108 will-overwrite to the current tip (see rules above, which show that
 109 this is OK).  Or maybe to the last pseudomerge on the current tip,
 110 so that the overall result will be series of pseudomerges.
 111