From 5958f33adfaa49981accb3cd4036916ac8daf64e Mon Sep 17 00:00:00 2001
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun, 18 Feb 2018 11:57:09 +0000
Subject: git-debrebase: Recognise anchors by commit annotation

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
 git-debrebase | 83 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 41 insertions(+), 42 deletions(-)

(limited to 'git-debrebase')

diff --git a/git-debrebase b/git-debrebase
index b9f36ca..92fa86b 100755
--- 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");
 }
 
-- 
cgit v1.2.3