2 more tests, see "todo" in gdr-editw
4 git-debrebase(5) data model
5 git-debrebase(1) command line
7 dgit-maint-debrebase(7)
9 clean up remains of NOTES and README
11 # git-ffqrebase start [BASE]
12 # # records previous HEAD so it can be overwritten
13 # # records base for future git-ffqrebase
14 # git-ffqrebase set-base BASE
15 # git-ffqrebase <git-rebase options>
16 # git-ffqrebase finish
17 # git-ffqrebase status [BRANCH]
19 # refs/ffq-prev/REF relates to refs/REF
21 # git-debrebase without start, if already started, is willing
22 # to strip pseudomerges provided that they overwrite exactly
24 # xxxx is this right ? what matters is have we pushed
25 # I think in fact the right answer is:
26 # git-debrebase always strips out pseudomerges from its branch
27 # a pseudomerge is put in at the time we want to push
28 # at that time, we make a pseudomerge of the remote tracking
29 # branch (if raw git) or the dgit view (if dgit)
30 # for raw git git-ffqrebase, do want preciseley to record
31 # value of remote tracking branch or our branch, on start, so we
32 # overwrite only things we intend to
33 # the previous pseudomerge check for tags and remote branches ?
40 [git-debrebase[ COMMIT-TYPE [ ARGS...]]: PROSE, MORE PROSE]
42 [git-debrebase: split mixed commit, debian part]
43 [git-debrebase: split mixed commit, upstream-part]
44 [git-debrebase: convert dgit import, debian changes]
45 [git-debrebase breakwater: convert dgit import, upstream changes]
47 [git-debrebase upstream-combine . PIECE[ PIECE...]: new upstream]
48 [git-debrebase breakwater: new upstream NEW-UPSTREAM-VERSION, merge]
49 [git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog]
51 [git-debrebase: gbp2debrebase, drop patches]
52 [git-debrebase breakwater: declare upstream]
53 [git-debrebase pseudomerge: stitch]
55 m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
57 Every breakwater commit must be a merge. In principle, this is not
58 necessary. After all, we are relying on the
59 [git-debrebase breakwater: ...]
60 commit message annotation in "declare" breakwater merges (which
61 do not have any upstream changes), to distinguish those breakwater
62 merges from ordinary pseudomerges (which we might just try to strip).
64 However, the user is going to be doing git-rebase a lot. We really
65 don't want them to rewrite a breakwater base commit. git-rebase
66 trips up on merges, so that is a useful safety catch.
73 git-debrebase blah [implies start] strips pseudomerge(s)
75 commit / git-debrebase / etc.
78 hook: call git-debrebase prep-push adds new pm ? passes --overwrite ?
79 dgit push does not update remote
81 commit / git-debrebase / etc. strips pm(s) including last one
84 hook: call git-debrebase prep-push adds new pm ? passes --overwrite ?
85 dgit push DOES update remote
87 commit / git-debrebase / etc. strips last pm, but arranges
88 that remade pm will incorporate it
92 When we strip a pm, we need to maybe record it (or something) as the
95 We do this if the pm is contained within the output branch.
97 Actually this is not special to PMs.
99 We need to record a new to-be-overwritten commit
100 merge-base( our branch tip, relevant remote )
102 If this is not a descendant of the relevant remote, then we are going
103 to have a problem when we push so issue a warning or fail.
109 git-debrebase start or git-debrebase [continue]
111 with no recorded will-overwrite
113 putative will-overwrite is
116 obviously it is safe to say we will overwrite this
117 we do not need to worry about whether this will
118 overwrite not-included changes in the remote
119 because either the will-overwrite is not
120 ff from the remote (in which case later failure,
121 see below); or the will-overwrite _is_ ff
122 from the remote ie our tip is later than the
123 remote and includes all of its changes
125 this model tends to keep ad-hoc commits made on our
126 tip branch before we did rebase start, in the
127 `interchange view' and also in the rebase stack.
130 merge-base( current remote, current tip )
132 it is safe to overwrite current tip, by the
135 it is always safe to rewind will-overwrite: all
136 that does is overwrite _less_ stuff
138 this is the earliest overwrite we can make that
139 will be pushable to the remote
141 in practical terms this can only be ff from the
142 current remote if it is equal to the current remote;
143 so what we are actually checking below is that our tip
144 is ff from the remote. This ought to be true before
145 the first of our rebases.
147 this model tends to rewind and rebase ad-hoc commits
148 made on our tip branch before we did rebase start,
151 in any case putative will-overwrite must be ff from remote.
152 Otherwise when we push it will not be ff, even though we have
153 made pseudomerge to overwrite will-overwrite. So if we spot
154 this, report an error.
156 with a recorded will-overwrite
158 we may need to advance will-overwrite, to allow us to generate
159 future pseudomerges that will be pushable
161 advancing will-overwrite is dangerous, since it might
162 effectively cancel the commits that will-ovewrite is advanced
165 we advance it to merge-base( current remote, current tip )
166 if possible (see above), - ie to current remote, subject
167 to the condition that that is an ancestor of current tip
169 In each case we can strip pseudomerges freely, as needed. We do not
170 want to record what pseudomerges we strip, because whether we need to
171 keep them depends (only) on whether they have been pushed.
173 Is that actually true ? What if the user actually _wanted_ to keep
174 the pseudomerge despite not having pushed it ?
176 In that case we need to advance will-overwrite past it. We could
177 provide an explicit command to do this: it would advance
178 will-overwrite to the current tip (see rules above, which show that
179 this is OK). Or maybe to the last pseudomerge on the current tip,
180 so that the overall result will be series of pseudomerges.
182 ========================================
184 So, pm handling specifics:
186 strategy is to avoid making needless pseudomerges
187 pseudomerges that exist will be preserved
188 (by being included in will-overwrite)
190 This is good because the presence of a pseudomerge means we know we
191 want to keep it; and that allows explicit control over history detail
194 It does mean we must avoid making the pseudomerges unnecessarily.
195 They should be made just before (ideally, part of) dgit push.
197 1. git-debrebase [-i etc.]
200 check for will-overwrite
201 if is already a will-overwrite, fine, do no more
204 check our origin branch exists and we are ff from it
207 check our other might-be-pushed to branches
208 check we are ff from them
211 set will-overwrite to something which is ff from
214 we use our tip, as discussed above
215 (optionally, can use some other commit which is ff
216 from all of the above, eg one of them)
218 N. git-debrebase [--noop-ok] record-ffq-prev
220 does what is described above
222 2. git-debrebase [--noop-ok] stitch
224 makes pseudomerge with will-overwrite
225 deletes will-overwrite
227 we will teach dgit to do
230 3. git-debrebase push
232 like git push only does stitch first
233 ??? command line parsing!
235 4. git-debrebase release
237 stiches, finalises changelog, signs tags, pushes everything
238 for the future, when there is some automatic builder
240 will-overwrite for each ref
245 ========================================
249 [ all this is done now:
251 current HEAD (patches-unapplied),
252 this is going to be the base of the old breakwater
256 HEAD:<upstream> = upstream:<upstream>
257 upstream..HEAD:<upstream> is empty (overrideable)
258 upstremm:debian is empty (overrideable)
262 run gbp pq import to generate pq branch
265 commit to remove d/patches
266 breakwater pseudomerge with upstream
267 "rebase" of pq branch, each commit with d/patches stripped
270 what about dgit view branch ?
271 ideally, would make pseudomerge over dgit view
272 would need to check that dgit view is actually dgit view of
274 failing that first push will need --overwrite
276 should this be called import or gbp2debrebase as it is now ?
277 gbp uses "import" oddly but I'm tempted to use it normally here.