As discussed by private e-mail, git-debrebase should defer to
`git-deborig --just-print`'s determination of the tag corresponding to a
given upstream release, rather than reimplementing the algorithm.

In a message I proposed doing it like this:

  couldn't find any of the following tags: 2.1x, v2.1x, upstream/2.1x
  tell me a tag or branch head to make an orig.tar from: git deborig
  --version=2.1x --just-print COMMITTISH
  git-debrebase: failed command: git-deborig --version=2.1x --just-print
  git-debrebase: subprocess failed with error exit status 1
  git-debrebase: git-deborig was unable to find a
  unique committish corresponding to upstream version 2.1.  Supply a
  commitish as the second argument to new-upstream, e.g.:
       git debrebase new-upstream 2.1 v2.1 <more args ..>

In a private email conversation, I wrote:
error message as nice as possible.

I have found that error messages which contain error output from
subprograms are often confusing to people.  This may not matter much
in programs to be used only with care by experts, or in unusual error
cases.

But this one is a very usual error case.  Existing practice in
src:dgit for "expected" errors has been to write bespoke error
handling code to try to produce the best error message.

Sean Whitton writes ("Bug#903392: want support for packaging-only maintainer views"):

I think the right change to git-deborig depends on the possible future
changes to the algorithm.

A. If the algorithm is only going to be changed to add different tag
   construction formats:

   Then I would like an option for git-deborig to print the list of
   tags to try for a version.  (It wouldn't need to do any ref lookup;
   not having it do the ref lookup would mean that in theory a caller
   which finds several refs and knows how to sort wheat from chaff
   would be able to do so.)

B. If the algorithm is going to be changed to do god knows what else.
   (Look for things that aren't tags?  Look online somehow?  Find a
   tree but since the interface says commitish, make a commit up out
   of whole cloth?  Sort wheat from chaff itself?)

   Then we may need a more complicated interface.

But, presumably, whatever change of kind B, it would be an optional
enhancement.  And it seems unlikely.  So I suggest:

  git-deborig --just-print-tag-names [--version=VERSION]

which prints a list of tag names one per line, and which does not need
a git tree and does not look up the tags to see if they exist.  (I
don't care much about other errors, eg what it does if VERSION is
syntactically wrong or the changelog cannot be read or something.)

If an extension of type B occurs, then gdr (and, soon, dgit) will not
benefit from it until src:dgit is taught how to ask git-deborig about
it.

So this plan allows git-deborig to expose its current special
knowledge - the list of tag formats - while allowing its caller to
remain completely in control of the UI.

Sorry to be picky.

Ian.

control: tag 931180 +patch

Hello,

https://salsa.debian.org/debian/devscripts/merge_requests/131

Hello,

In #1105759 we are discussing how git-debpush could get upstream tag
information out of debian/gbp.conf.  Ian and I are talking about this,
and we realised that git-debrebase could benefit from this functionality
just as much as git-debpush.

After talking about how to do that we came to the conclusion that the
most sensible thing is to add this functionality to git-deborig itself.

Then, in order to fix #1108181 at the same time, we would like to move
git-deborig from bin:devscripts to bin:git-debpush, have bin:git-debpush
no longer depend on bin:devscripts, and finally have bin:dgit and
bin:git-debrebase depend on bin:git-debpush.

I'll do that once we've released trixie.

Hello,

Probably git-debrebase's implementation of this ought to move to
Debian::Dgit::Core, and git-deborig should use it from there.
So sort of the inverse of this bug: make git-deborig use git-debrebase's
implementation.

There are some other things in this bug about error messages so not
reassigning & retitling for now.