git-debrebase: classify: tolerate backwards breakwater merges

1 files changed, 18 insertions, 12 deletions

diff --git a/git-debrebase b/git-debrebase
index a3733a9..8f2e922 100755
--- a/git-debrebase
+++ b/git-debrebase
@@ -390,8 +390,6 @@ sub classify ($) {
     my ($stype, $series) = git_cat_file "$t:debian/patches/series";
     my $haspatches = $stype ne 'missing' && $series =~ m/^\s*[^#\n\t ]/m;
 
-@p = reverse @p; #xxx
-
     # How to decide about l/r ordering of breakwater merges ?  git
     # --topo-order prefers to expand 2nd parent first.  There's
     # already an easy rune to look for debian/ history anyway (git log
@@ -399,17 +397,25 @@ sub classify ($) {
     # way also there's also an easy rune to look for the upstream
     # patches (--topo-order).
 
-    my $prevbrw = 0;
-
-    if (@p == 2 &&
-	!$haspatches &&
-	!$p[$prevbrw]{IsOrigin} && # breakwater never starts with an origin
-	!($p[$prevbrw]{Differs} & ~D_DEB) &&
-	!($p[!$prevbrw]{Differs} & ~D_UPS)) {
-	return $classify->(qw(BreakwaterUpstreamMerge),
-			   OrigParents => [ $p[!$prevbrw] ]);
+    # The above tells us which way *we* will generate them.  But we
+    # might encounter ad-hoc breakwater merges generated manually,
+    # which might be the other way around.  In principle, in some odd
+    # situations, a breakwater 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} & ~D_DEB) &&
+	    !($p[!$prevbrw]{Differs} & ~D_UPS)) {
+	    return $classify->(qw(BreakwaterUpstreamMerge),
+			       OrigParents => [ $p[!$prevbrw] ]);
+	}
+	# xxx multi-.orig upstreams
     }
-    # xxx multi-.orig upstreams
 
     return $unknown->("complex merge");
 }