+ if ($r->{Msg} =~ m{^\[git-debrebase anchor.*\]$}m) {
+ # multi-orig upstreams are represented with an anchor merge
+ # from a single upstream commit which combines the orig tarballs
+
+ my $badanchor = sub { $unknown->("git-debrebase \`anchor' but @_"); };
+ @p == 2 or return $badanchor->("has other than two parents");
+ $haspatches and return $unknown->("contains debian/patches");
+
+ # How to decide about l/r ordering of anchors ? git
+ # --topo-order prefers to expand 2nd parent first. There's
+ # already an easy rune to look for debian/ history anyway (git log
+ # debian/) so debian breakwater branch should be 1st parent; that
+ # way also there's also an easy rune to look for the upstream
+ # patches (--topo-order).
+
+ # The above tells us which way *we* will generate them. But we
+ # might encounter ad-hoc anchor merges generated manually,
+ # which might be the other way around. In principle, in some odd
+ # situations, an anchor merge might have two identical parents.
+ # In that case we guess which way round it is (ie, which parent
+ # has the upstream history). The order of the 2-iteration loop
+ # controls which guess we make.
+
+ # XXX we are going to desupport non-git-debrebase-generated anchors
+
+ foreach my $prevbrw (qw(0 1)) {
+ if (!$p[$prevbrw]{IsOrigin} && # breakwater never starts with an origin
+ !($p[!$prevbrw]{Differs} & ~DS_DEB) && # no non-debian changess
+ !($p[$prevbrw]{Differs} & ~D_UPS)) { # no non-upstream changes
+ return $classify->(qw(Anchor),
+ OrigParents => [ $p[!$prevbrw] ]);
+ }