+ if (grep { $_ eq $objid } @opt_anchors) {
+ return $classify->('TreatAsAnchor');
+ }
+
+ my @identical = grep { !$_->{Differs} } @p;
+ my ($stype, $series) = git_cat_file "$t:debian/patches/series";
+ my $haspatches = $stype ne 'missing' && $series =~ m/^\s*[^#\n\t ]/m;
+
+ 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
+
+ # Every anchor tagged this way must be a merge.
+ # We are relying on the
+ # [git-debrebase anchor: ...]
+ # commit message annotation in "declare" anchor merges (which
+ # do not have any upstream changes), to distinguish those
+ # anchor merges from ordinary pseudomerges (which we might
+ # just try to strip).
+ #
+ # However, the user is going to be doing git-rebase a lot. We
+ # really don't want them to rewrite an anchor commit.
+ # git-rebase trips up on merges, so that is a useful safety
+ # catch.
+ #
+ # BreakwaterStart commits are also anchors in the terminology
+ # of git-debrebase(5), but they are untagged (and always
+ # manually generated).
+ #
+ # We cannot not tolerate any tagged linear commit (ie,
+ # BreakwaterStart commits tagged `[anchor:') because such a
+ # thing could result from an erroneous linearising raw git
+ # rebase of a merge anchor. That would represent a corruption
+ # of the branch. and we want to detect and reject the results
+ # of such corruption before it makes it out anywhere. If we
+ # reject it here then we avoid making the pseudomerge which
+ # would be needed to push it.
+
+ my $badanchor = sub { $unknown->("git-debrebase \`anchor' but @_"); };
+ @p == 2 or return $badanchor->("has other than two parents");
+ $haspatches and return $badanchor->("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).
+
+ # Also this makes --first-parent be slightly more likely to
+ # be useful - it makes it provide a linearised breakwater history.
+
+ # Of course one can say somthing like
+ # gitk -- ':/' ':!/debian'
+ # to get _just_ the commits touching upstream files, and by
+ # the TREESAME logic in git-rev-list this will leave the
+ # breakwater into upstream at the first anchor. But that
+ # doesn't report debian/ changes at all.
+
+ # Other observations about gitk: by default, gitk seems to
+ # produce output in a different order to git-rev-list. I
+ # can't seem to find this documented anywhere. gitk
+ # --date-order DTRT. But, gitk always seems to put the
+ # parents from left to right, in order, so it's easy to see
+ # which way round a pseudomerge is.
+
+ $p[0]{IsOrigin} and $badanchor->("is an origin commit");
+ $p[1]{Differs} & ~DS_DEB and
+ $badanchor->("upstream files differ from left parent");
+ $p[0]{Differs} & ~D_UPS and
+ $badanchor->("debian/ differs from right parent");
+
+ return $classify->(qw(Anchor),
+ OrigParents => [ $p[1] ]);
+ }