3 git-debrebase blah [implies start] strips pseudomerge(s)
5 commit / git-debrebase / etc.
8 hook: call git-debrebase prep-push adds new pm ? passes --overwrite ?
9 dgit push does not update remote
11 commit / git-debrebase / etc. strips pm(s) including last one
14 hook: call git-debrebase prep-push adds new pm ? passes --overwrite ?
15 dgit push DOES update remote
17 commit / git-debrebase / etc. strips last pm, but arranges
18 that remade pm will incorporate it
22 When we strip a pm, we need to maybe record it (or something) as the
25 We do this if the pm is contained within the output branch.
27 Actually this is not special to PMs.
29 We need to record a new to-be-overwritten commit
30 merge-base( our branch tip, relevant remote )
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.
39 git-debrebase start or git-debrebase [continue]
41 with no recorded will-overwrite
43 putative will-overwrite is
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
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.
60 merge-base( current remote, current tip )
62 it is safe to overwrite current tip, by the
65 it is always safe to rewind will-overwrite: all
66 that does is overwrite _less_ stuff
68 this is the earliest overwrite we can make that
69 will be pushable to the remote
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.
77 this model tends to rewind and rebase ad-hoc commits
78 made on our tip branch before we did rebase start,
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.
86 with a recorded will-overwrite
88 we may need to advance will-overwrite, to allow us to generate
89 future pseudomerges that will be pushable
91 advancing will-overwrite is dangerous, since it might
92 effectively cancel the commits that will-ovewrite is advanced
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
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.
103 Is that actually true ? What if the user actually _wanted_ to keep
104 the pseudomerge despite not having pushed it ?
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.