3 dgit-maint-debrebase(7)
4 someone should set branch.<name>.mergeOptions to include --ff-only ?
6 arrange for dgit to automatically stitch on push
7 dgit push usually needs to (re)make a pseudomerge. The "first"
8 git-debrebase stripped out the previous pseudomerge and could
9 remembeed the old HEAD. But the user has to manually stitch it.
10 To fix this, do we need a new push hook for dgit ?
16 git-debrebase blah [implies start] strips pseudomerge(s)
18 commit / git-debrebase / etc.
21 hook: call git-debrebase prep-push dgit push does not update remote
22 or something, must add patches at least
24 commit / git-debrebase / etc. strips patches
27 hook: call git-debrebase prep-push dgit push DOES update remote
29 commit / git-debrebase / etc. strips last pm, but arranges
30 that remade pm will incorporate it
33 # problems / outstanding questions:
35 # * dgit push with a `3.0 (quilt)' package means doing quilt
36 # fixup. Usually this involves recommitting the whole patch
37 # series, one at a time, with dpkg-source --commit. This is
38 # terribly terribly slow. (Maybe this should be fixed in dgit.)
40 # * Workflow is currently clumsy. Lots of spurious runes to type.
41 # There's not even a guide.
43 # * new-upstream-v0 has a terrible UI for multiple upstream pieces.
44 # You end up with giant runic command lines. Does this matter /
45 # One consequence of the lack of richness it can need -f in
46 # fairly sensible situations.
48 # * There should be a good convention for the version number,
49 # and unfinalised or not changelog, after new-upstream.
51 # * Handing of multi-orig dgit new-upstream .dsc imports is known to
52 # be broken. They may be not recognised, improperly converted, or
53 # their conversion may be unrecognised.
55 # * We need to develop a plausible model that works for derivatives,
56 # who probably want to maintain their stack on top of Debian's.
57 # downstream-rebase-launder-v0 may be a starting point?
58 # maybe the hypothetical git-ffqrebase is part of it too.
61 # undocumented usages:
63 # git-debrebase [<options>] downstream-rebase-launder-v0 # experimental
66 ========================================
70 refs/ffq-prev/REF relates to refs/REF
72 When we strip a pm, we need to maybe record it (or something) as the
77 with no recorded ffq-prev
79 ffq-prev is our current tip
81 obviously it is safe to say we will overwrite this
82 we do check whether there are not-included changes in the remotes
83 because if the new ffq-prev is not ff from the remotes
84 the later pushes will fail
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.
90 also we can explicitly preserve with
93 It is always safe to rewind ffq-prev: all
94 that does is overwrite _less_ stuff.
96 in any case putative ffq-prev must be ff from remote.
97 Otherwise when we push it will not be ff, even though we have
98 made pseudomerge to overwrite ffq-prev. So if we spot
99 this, report an error. see above
101 with a recorded ffq-prev
103 we may need to advance ffq-prev, to allow us to generate
104 future pseudomerges that will be pushable
106 advancing ffq-prev is dangerous, since it might
107 effectively cancel the commits that will-ovewrite is advanced
110 ??? advance it to merge-base( current remote, current tip )
111 if possible (see above), - ie to current remote, subject
112 to the condition that that is an ancestor of current tip
114 currently this is not implemented
116 better maybe to detect divergence ? but it is rather late
119 We check we are ff from remotes before recording new ffq-prev
121 ---------- now follows much the same info in different words ----------
123 Re git-debrebase [--noop-ok] stitch
125 we will teach dgit to do
129 following parts are not implemented and maybe aren't the
130 best subcommand names etc.
132 3. git-debrebase push
134 like git push only does stitch first
135 ??? command line parsing!
137 4. git-debrebase release
139 stiches, finalises changelog, signs tags, pushes everything
140 for the future, when there is some automatic builder
142 ========================================
146 what about dgit view branch ?
147 ideally, would make pseudomerge over dgit view
148 would need to check that dgit view is actually dgit view of
150 failing that first push will need --overwrite
151 that is what is currently implemented
153 ========================================
155 how to handle divergence and merges (if not detected soon enough)
158 if merge, look at branches before merge
159 generate new combined branch
160 pseudomerge to overwrite merge
162 current avaiable strategies:
164 maybe launder foreign branch
166 if foreign branch is nmuish, can rebase it onto ours
168 could merge breakwaters (use analyse to find them)
169 merge breakwaters (assuming same upstream)
170 manually construct new patch queue by inspection of
171 the other two patch queues
173 instead of manually constructing patch queue, could use
174 gbp pq export and git merge the patch queues
175 (ie work with interdiffs)
177 if upstreams are different and one is ahead
178 simply treat that as "ours" and
179 do the work to import changes from the other
181 if upstreams have diverged, can
182 resolve somehow to make new upstream
183 do new-upstream on each branch separately
184 now reduced to previously "solved" problem
186 in future, auto patch queue merge algorithm
187 determine next patch to apply
188 there are three versions o..O, l..L, r..R
189 we have already constructed m (previous patch or merged breakwater)
190 try using vector calculus in the implied cube and compute
191 multiple ways to check consistency ?
193 ========================================
195 For downstreams of Debian, sketch of git-ffqrebase
197 # git-ffqrebase start [BASE]
198 # # records previous HEAD so it can be overwritten
199 # # records base for future git-ffqrebase
200 # git-ffqrebase set-base BASE
201 # git-ffqrebase <git-rebase options>
202 # git-ffqrebase finish
203 # git-ffqrebase status [BRANCH]