chiark / gitweb /
git-debrebase: conclude, quick: uncleanness after laundry is fatal
[dgit.git] / NOTES.git-debrebase
1 TODO
2    tutorial
3       dgit-maint-debrebase(7)
4       someone should set branch.<name>.mergeOptions to include --ff-only ?
5
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 ?
11
12
13
14 workflow
15
16   git-debrebase blah [implies start]       strips pseudomerge(s)
17
18   commit / git-debrebase / etc.
19
20   dgit --damp-run push
21       hook: call git-debrebase prep-push   dgit push does not update remote
22       or something, must add patches at least
23
24   commit / git-debrebase / etc.            strips patches
25
26   dgit push
27       hook: call git-debrebase prep-push   dgit push DOES update remote
28
29   commit / git-debrebase / etc.            strips last pm, but arranges
30                                            that remade pm will incorporate it
31
32
33 # problems / outstanding questions:
34 #
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.)
39 #
40 #  * Workflow is currently clumsy.  Lots of spurious runes to type.
41 #    There's not even a guide.
42 #
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.
47 #
48 #  * There should be a good convention for the version number,
49 #    and unfinalised or not changelog, after new-upstream.
50 #
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.
54 #
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.
59         
60
61 # undocumented usages:
62 #
63 #    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
64
65
66 ========================================
67
68 Theory for ffq-prev
69
70   refs/ffq-prev/REF    relates to refs/REF
71
72 When we strip a pm, we need to maybe record it (or something) as the
73 new start point.
74
75 When we do a thing
76
77     with no recorded ffq-prev
78
79         ffq-prev is our current tip
80
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
85
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.
89
90         also we can explicitly preserve with
91         git-debrebase stitch
92
93         It is always safe to rewind ffq-prev: all
94         that does is overwrite _less_ stuff.
95
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
100
101     with a recorded ffq-prev
102
103         we may need to advance ffq-prev, to allow us to generate
104         future pseudomerges that will be pushable
105
106         advancing ffq-prev is dangerous, since it might
107         effectively cancel the commits that will-ovewrite is advanced
108         over.
109
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
113
114         currently this is not implemented
115
116         better maybe to detect divergence ?  but it is rather late
117         by then!
118
119 We check we are ff from remotes before recording new ffq-prev
120
121   ---------- now follows much the same info in different words ----------
122
123 Re git-debrebase [--noop-ok] stitch
124
125     we will teach dgit to do
126        git-debrebase stitch
127     or some such ?
128
129 following parts are not implemented and maybe aren't the
130 best subcommand names etc.
131
132 3. git-debrebase push
133
134     like git push only does stitch first
135     ??? command line parsing!
136
137 4. git-debrebase release
138
139     stiches, finalises changelog, signs tags, pushes everything
140     for the future, when there is some automatic builder
141
142 ========================================
143
144 import from gbp
145
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
149   ond of our ancestors
150 failing that first push will need --overwrite
151 that is what is currently implemented
152
153 ========================================
154
155 how to handle divergence and merges (if not detected soon enough)
156
157 same problem
158  if merge, look at branches before merge
159  generate new combined branch
160  pseudomerge to overwrite merge
161
162 current avaiable strategies:
163
164  maybe launder foreign branch
165
166  if foreign branch is nmuish, can rebase it onto ours
167
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
172
173  instead of manually constructing patch queue, could use
174   gbp pq export and git merge the patch queues
175   (ie work with interdiffs)
176
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
180
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
185
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 ?
192
193 ========================================
194
195 For downstreams of Debian, sketch of git-ffqrebase
196
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]