Fix upstream_commitish_search API

upstream_commitish_search used to return a commit.  If it succeeded
The caller could find the tag in $tried[-1].  Both callers relied on
this unpleasant and error-prone API.

In
   0bb8e2a87e3c8b5be0fce5c2491b292e9273056e
   Dgit::upstream_commitish_search: fail if more than one tag exists

the algorithm was changed to keep looking, so it can reject ambiguous
situations.  The result is that $tried[-1] is entirely wrong in the
success case.  (This is spotted by the tagupl-baredebian test.)

It would have been possible to fix this by making
upstream_commitish_search synthesise a suitable return value for
putting in $tried, but that is absurd.

Instead give this function a sensible calling convention.  It now
returns a list of the tag name (for messages etc.) and the
commitish (for use).  Change both call sites.

CC: Sean Whitton <spwhitton@spwhitton.name>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

1 files changed, 3 insertions, 2 deletions

diff --git a/git-debrebase b/git-debrebase
index 171249f..340a590 100755
--- a/git-debrebase
+++ b/git-debrebase
@@ -2697,9 +2697,10 @@ END
     if (!@upstreams) {
 	if ($do_tags) {
 	    my @tried;
-	    my $ups_rev = upstream_commitish_search $version, \@tried;
+	    my ($ups_tag, $ups_rev) =
+	        upstream_commitish_search $version, \@tried;
 	    if ($ups_rev) {
-		my $this = f_ "git tag %s", $tried[-1];
+		my $this = f_ "git tag %s", $ups_tag;
 		push @upstreams, { Commit => $ups_rev,
 				   Source => $this,
 				 };