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