chiark / gitweb /
dgit(1): In --include-dirty caveat, say "especially --clean=git"
[dgit.git] / NOTES.git-debrebase
1 # problems / outstanding questions:
2 #
3 #  * new-upstream has an awkward UI for multiple upstream pieces.
4 #    You end up with giant runic command lines.  Does this matter /
5 #    One consequence of the lack of richness it can need -f in
6 #    fairly sensible situations.
7 #
8 #  * There should be a good convention for the version number,
9 #    and unfinalised or not changelog, after new-upstream.
10 #
11 #  * Handing of multi-orig dgit new-upstream .dsc imports is known to
12 #    be broken.  They may be not recognised, improperly converted, or
13 #    their conversion may be unrecognised.
14 #
15 #  * We need to develop a plausible model that works for derivatives,
16 #    who probably want to maintain their stack on top of Debian's.
17 #    downstream-rebase-launder-v0 may be a starting point?
18 #    maybe the hypothetical git-ffqrebase is part of it too.
19         
20
21 # undocumented usages:
22 #
23 #    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental
24
25
26 ========================================
27
28 Theory for ffq-prev
29
30   refs/ffq-prev/REF    relates to refs/REF
31
32 When we strip a pm, we need to maybe record it (or something) as the
33 new start point.
34
35 When we do a thing
36
37     with no recorded ffq-prev
38
39         ffq-prev is our current tip
40
41         obviously it is safe to say we will overwrite this
42         we do check whether there are not-included changes in the remotes
43         because if the new ffq-prev is not ff from the remotes
44         the later pushes will fail
45
46         this model tends to keep ad-hoc commits made on our
47         tip branch before we did rebase start, in the
48         `interchange view' and also in the rebase stack.
49
50         also we can explicitly preserve with
51         git-debrebase stitch
52
53         It is always safe to rewind ffq-prev: all
54         that does is overwrite _less_ stuff.
55
56         in any case putative ffq-prev must be ff from remote.
57         Otherwise when we push it will not be ff, even though we have
58         made pseudomerge to overwrite ffq-prev.  So if we spot
59         this, report an error.  see above
60
61     with a recorded ffq-prev
62
63         we may need to advance ffq-prev, to allow us to generate
64         future pseudomerges that will be pushable
65
66         advancing ffq-prev is dangerous, since it might
67         effectively cancel the commits that will-ovewrite is advanced
68         over.
69
70         ??? advance it to merge-base( current remote, current tip )
71         if possible (see above), - ie to current remote, subject
72         to the condition that that is an ancestor of current tip
73
74         currently this is not implemented
75
76         better maybe to detect divergence ?  but it is rather late
77         by then!
78
79 We check we are ff from remotes before recording new ffq-prev
80
81 ========================================
82
83 how to handle divergence and merges (if not detected soon enough)
84
85 same problem
86  if merge, look at branches before merge
87  generate new combined branch
88  pseudomerge to overwrite merge
89
90 current avaiable strategies:
91
92  maybe launder foreign branch
93
94  if foreign branch is nmuish, can rebase it onto ours
95
96  could merge breakwaters (use analyse to find them)
97  merge breakwaters (assuming same upstream)
98  manually construct new patch queue by inspection of
99   the other two patch queues
100
101  instead of manually constructing patch queue, could use
102   gbp pq export and git merge the patch queues
103   (ie work with interdiffs)
104
105  if upstreams are different and one is ahead
106   simply treat that as "ours" and
107   do the work to import changes from the other
108
109  if upstreams have diverged, can
110   resolve somehow to make new upstream
111   do new-upstream on each branch separately
112   now reduced to previously "solved" problem
113
114  in future, auto patch queue merge algorithm
115   determine next patch to apply
116   there are three versions o..O, l..L, r..R
117   we have already constructed m (previous patch or merged breakwater)
118   try using vector calculus in the implied cube and compute
119    multiple ways to check consistency ?
120
121 ========================================
122
123 For downstreams of Debian, sketch of git-ffqrebase
124
125 #    git-ffqrebase start [BASE]
126 #                # records previous HEAD so it can be overwritten
127 #                # records base for future git-ffqrebase
128 #    git-ffqrebase set-base BASE
129 #    git-ffqrebase <git-rebase options>
130 #    git-ffqrebase finish
131 #    git-ffqrebase status [BRANCH]