git-debrebase: Recognise anchors by commit annotation

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

diff --git a/git-debrebase b/git-debrebase
index b9f36ca5d3cab9a146d9bc1d247f62626c10e984..92fa86b7483ca92cea57de2bafb7835573068961 100755 (executable)
--- a/git-debrebase
+++ b/git-debrebase
@@ -402,13 +402,48 @@ sub classify ($) {
        return $r;
     };
 
-    my $claims_to_be_anchor =
-       $r->{Msg} =~ m{^\[git-debrebase anchor.*\]$}m;
+    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 (@p == 1) {
-       if ($claims_to_be_anchor) {
-           return $unknown->("single-parent git-debrebase anchor \`merge'");
+    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] ]);
+           }
        }
+
+       $badanchor->("violation");
+    }
+
+    if (@p == 1) {
        my $d = $r->{Parents}[0]{Differs};
        if ($d == D_PAT_ADD) {
            return $classify->(qw(AddPatches));
@@ -441,11 +476,7 @@ sub classify ($) {
        return $unknown->("origin commit");
     }
 
-    my @identical = grep { !$_->{Differs} } @p;
-    if (@p == 2 && @identical == 1 && !$claims_to_be_anchor
-       # anchor merges can look like pseudomerges, if they are
-       # "declare" commits (ie, there are no upstream changes)
-       ) {
+    if (@p == 2 && @identical == 1) {
        my @overwritten = grep { $_->{Differs} } @p;
        confess "internal error $objid ?" unless @overwritten==1;
        return $classify->(qw(Pseudomerge),
@@ -487,38 +518,6 @@ sub classify ($) {
                           OrigParents => \@orig_ps);
     }
 
-    my ($stype, $series) = git_cat_file "$t:debian/patches/series";
-    my $haspatches = $stype ne 'missing' && $series =~ m/^\s*[^#\n\t ]/m;
-
-    # 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.
-
-    foreach my $prevbrw (qw(0 1)) {
-       if (@p == 2 &&
-           !$haspatches &&
-           !$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] ]);
-       }
-    }
-
-    # multi-orig upstreams are represented with an anchor merge
-    # from a single upstream commit which combines the orig tarballs
-
     return $unknown->("complex merge");
 }