Package: devscripts Version: 2.19.5 Severity: minor Control: block 901926 by -1
Hello, This is a feature request to enable code reuse in git-debrebase: On Mon 20 May 2019 at 11:05am +0100, Ian Jackson wrote: > 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. -- Sean Whitton
signature.asc
Description: PGP signature
