NOTES.git-debrebase 4.22 KB
Newer Older
1 2
# problems / outstanding questions:
#
3
#  * new-upstream has an awkward UI for multiple upstream pieces.
4
#    You end up with giant runic command lines.  Does this matter /
5 6
#    One consequence of the lack of richness it can need -f in
#    fairly sensible situations.
7
#
8
#  * There should be a good convention for the version number,
9 10 11 12 13 14 15 16 17
#    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?
18
#    maybe the hypothetical git-ffqrebase is part of it too.
19 20
	

21 22 23 24 25
# undocumented usages:
#
#    git-debrebase [<options>] downstream-rebase-launder-v0  # experimental


26
========================================
27

28
Theory for ffq-prev
29

30 31
  refs/ffq-prev/REF    relates to refs/REF

32 33
When we strip a pm, we need to maybe record it (or something) as the
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 42 43 44
        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
45

46 47 48
        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.
49

50 51
        also we can explicitly preserve with
        git-debrebase stitch
52

53 54
	It is always safe to rewind ffq-prev: all
	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 59
        made pseudomerge to overwrite ffq-prev.  So if we spot
        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 65
        future pseudomerges that will be pushable

66
        advancing ffq-prev is dangerous, since it might
67 68 69
        effectively cancel the commits that will-ovewrite is advanced
        over.

70
        ??? advance it to merge-base( current remote, current tip )
71 72 73
        if possible (see above), - ie to current remote, subject
        to the condition that that is an ancestor of current tip

74
        currently this is not implemented
75

76 77
        better maybe to detect divergence ?  but it is rather late
        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 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

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 ?
120 121 122

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

123 124
For downstreams of Debian, sketch of git-ffqrebase

125 126 127 128 129 130 131
#    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]