chiark / gitweb /
git-debrebase: list tags currently written
[dgit.git] / NOTES.git-debrebase
1
2 #
3 #    git-ffqrebase start [BASE]
4 #                # records previous HEAD so it can be overwritten
5 #                # records base for future git-ffqrebase
6 #    git-ffqrebase set-base BASE
7 #    git-ffqrebase <git-rebase options>
8 #    git-ffqrebase finish
9 #    git-ffqrebase status [BRANCH]
10 #
11 #  refs/ffqrebase-prev/BRANCH    BRANCH may be refs/...; if not it means
12 #  refs/ffqrebase-base/BRANCH      refs/heads/BRANCH
13 #                               zero, one, or both of these may exist
14 #
15 # git-debrebase without start, if already started, is willing
16 # to strip pseudomerges provided that they overwrite exactly
17 # the previous HEAD
18 #  xxxx is this right ?  what matters is have we pushed
19 #    I think in fact the right answer is:
20 #       git-debrebase always strips out pseudomerges from its branch
21 #       a pseudomerge is put in at the time we want to push
22 #       at that time, we make a pseudomerge of the remote tracking
23 #           branch (if raw git) or the dgit view (if dgit)
24 #       for raw git git-ffqrebase, do want preciseley to record
25 #           value of remote tracking branch or our branch, on start, so we
26 #           overwrite only things we intend to
27 #  the previous pseudomerge    check for tags and remote branches ?
28
29
30 =========
31
32 special commit tags
33
34 [git-debrebase split mixed commit: debian part]
35 [git-debrebase split mixed commit: upstream part]
36 [git-debrebase convert dgit import: debian changes]
37 [git-debrebase convert dgit import: upstream changes]
38
39 [git-debrebase new-upstream combine . [PIECES...]]
40 [git-debrebase new-upstream breakwater NEW-UPSTREAM-VERSION]
41 [git-debrebase new-upstream changelog NEW-UPSTREAM-VERSION]
42
43 [git-debrebase gbp2debrebase drop-patches]
44 [git-debrebase declare-upstream breakwater]
45
46 m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]}
47
48 =========
49
50 workflow
51
52   git-debrebase blah [implies start]       strips pseudomerge(s)
53
54   commit / git-debrebase / etc.
55
56   dgit --damp-run push
57       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
58                                            dgit push does not update remote
59
60   commit / git-debrebase / etc.            strips pm(s) including last one
61
62   dgit push
63       hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
64                                            dgit push DOES update remote
65
66   commit / git-debrebase / etc.            strips last pm, but arranges
67                                            that remade pm will incorporate it
68
69 Aha!
70
71 When we strip a pm, we need to maybe record it (or something) as the
72 new start point.
73
74 We do this if the pm is contained within the output branch.
75
76 Actually this is not special to PMs.
77
78 We need to record a new to-be-overwritten commit
79    merge-base( our branch tip, relevant remote )
80
81 If this is not a descendant of the relevant remote, then we are going
82 to have a problem when we push so issue a warning or fail.
83
84
85
86 How about
87
88   git-debrebase start or git-debrebase [continue]
89
90     with no recorded will-overwrite
91
92         putative will-overwrite is 
93             one model:
94                 our current tip
95                 obviously it is safe to say we will overwrite this
96                 we do not need to worry about whether this will
97                     overwrite not-included changes in the remote
98                     because either the will-overwrite is not
99                     ff from the remote (in which case later failure,
100                     see below); or the will-overwrite _is_ ff
101                     from the remote ie our tip is later than the
102                     remote and includes all of its changes
103
104                 this model tends to keep ad-hoc commits made on our
105                 tip branch before we did rebase start, in the
106                 `interchange view' and also in the rebase stack.
107
108             other model:
109                 merge-base( current remote, current tip )
110
111                 it is safe to overwrite current tip, by the
112                 argument above
113
114                 it is always safe to rewind will-overwrite: all
115                 that does is overwrite _less_ stuff
116
117                 this is the earliest overwrite we can make that
118                     will be pushable to the remote
119
120                 in practical terms this can only be ff from the
121                 current remote if it is equal to the current remote;
122                 so what we are actually checking below is that our tip
123                 is ff from the remote.  This ought to be true before
124                 the first of our rebases.
125
126                 this model tends to rewind and rebase ad-hoc commits
127                 made on our tip branch before we did rebase start,
128                 this is better
129
130         in any case putative will-overwrite must be ff from remote.
131         Otherwise when we push it will not be ff, even though we have
132         made pseudomerge to overwrite will-overwrite.  So if we spot
133         this, report an error.
134
135     with a recorded will-overwrite
136
137         we may need to advance will-overwrite, to allow us to generate
138         future pseudomerges that will be pushable
139
140         advancing will-overwrite is dangerous, since it might
141         effectively cancel the commits that will-ovewrite is advanced
142         over.
143
144         we advance it to merge-base( current remote, current tip )
145         if possible (see above), - ie to current remote, subject
146         to the condition that that is an ancestor of current tip
147
148 In each case we can strip pseudomerges freely, as needed.  We do not
149 want to record what pseudomerges we strip, because whether we need to
150 keep them depends (only) on whether they have been pushed.
151
152 Is that actually true ?  What if the user actually _wanted_ to keep
153 the pseudomerge despite not having pushed it ?
154
155 In that case we need to advance will-overwrite past it.  We could
156 provide an explicit command to do this: it would advance
157 will-overwrite to the current tip (see rules above, which show that
158 this is OK).  Or maybe to the last pseudomerge on the current tip,
159 so that the overall result will be series of pseudomerges.
160
161 ========================================
162
163 import from gbp
164
165  inputs:
166    current HEAD (patches-unapplied),
167      this is going to be the base of the old breakwater
168    nominated upstream
169
170  checks:
171    HEAD:<upstream> = upstream:<upstream>
172    upstream..HEAD:<upstream> is empty (overrideable)
173    upstremm:debian is empty (overrideable)
174
175  procedure:
176    construct
177      run gbp pq import to generate pq branch
178      new breakwater is
179        old HEAD
180        commit to remove d/patches
181        breakwater pseudomerge with upstream
182        "rebase" of pq branch, each commit with d/patches stripped
183
184 what about dgit view branch ?
185 ideally, would make pseudomerge over dgit view
186 would need to check that dgit view is actually dgit view of
187   ond of our ancestors
188 failing that first push will need --overwrite