summaryrefslogtreecommitdiff
path: root/NOTES.git-debrebase
blob: 7b9a9b19f39c4b7b3928991ae932d0c3fe0586c9 (plain)
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
TODO
   reference docs
      git-debrebase(1)   command line
   tutorial
      dgit-maint-debrebase(7)
      someone should set branch.<name>.mergeOptions to include --ff-only ?

   clean up remains of README

   arrange for dgit to automatically stitch on push

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

========================================

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]