In a private email conversation, I wrote:
> Sean Whitton writes ("Re: git-debrebase cannot invoke git-deborig (was: Re:
> some manpage feedback)"):
> > On Sun, Jun 17 2018, Ian Jackson wrote:
> > > The problem is control of what happens when none of the tags exist.
> > > git-deborig naturally wants to print a helpful message. But that
> > > message is likely to be wrong for the gdr user.
> > >
> > > Conversely, *someone* needs to print the tags which were tried.
> > >
> > > So either we need to carefully coordinate the wording of git-deborig's
> > > and gdr's messages, or we need git-deborig to hand the list of tags to
> > > git-debrebase.
> > >
> > > The latter is fine if this is always going to be a list of tag
> > > formats. But what if it turns out to be branches or something ?
> > > Maybe that is unlikely.
> > >
> > > I guess I'm probably overthinking this.
> >
> > How about:
> >
> > [existing git deborig output]
> > [failed subprocess etc.etc. output from git-debrebase]
> > 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 ..>
> >
> > This output could be produced whenever git-deborig exits nonzero, or to
> > be more robust, I could have git-deborig exit with a different exit code
> > which specifically indicates no unique commitish.
>
> That would be tolerable, I guess. (Although the example ought to obe
> RELEASE-2.1 since v2.1 would be supported by git-deborig.) I will
> leave this as it is for now though I think...
I sat on this to think about it and I still think I want to make the
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 previously modified git-deborig to expose the results of its algorithm
> if you pass --just-print, but there was some further blocker to having
> gdr start using that algorithm instead of reimplementing it.
>
> Let me know if further changes to git-deborig are needed so that we can
> maintain this algorithm in one place in the archive.
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.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
