Package: git-debpush
Version: 14.5~bpo13+1
Severity: wishlist

Hi!  Recently I've been migrating my workflow from

git-debpush --upstream=upstream/1.2.3

to

git-debpush --upstream=v1.2.3

based on some debian-devel discussions suggesting recording upstream git
tags (with associated commit id) into Debian's dgit view may provide
some additional supply-chain feature.  It isn't clear to me if there is
sufficient consensus to actually recommend this style over the former,
or if there are any disadvantages with this style.  I'm using this style
to gain experience with it.

This has worked well, until I wanted to upload a version of a package
where upstream doesn't tag their releases, and we just track git:

jas@frallan:~/dpkg/golang-github-crawshaw-iox$ LANG=C git-debpush 
--remote=origin --upstream=c51c3df3079724bad60b626b5114e12cfa6cb859
fatal: ambiguous argument 
'refs/tags/c51c3df3079724bad60b626b5114e12cfa6cb859^{}': unknown revision or 
path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
jas@frallan:~/dpkg/golang-github-crawshaw-iox$ 

Indeed git-debpush --upstream is documented to accept only a git tag:

       --upstream=TAG
           When pushing a non-native package, git-debpush needs a tag for the 
upstream part of your package.

           By default git-debpush asks git-deborig(1), which searches for a 
suitable tag based on the upstream version in debian/changelog.

Thus this is a feature request to also support commit id in this field.

I dropped use of the --upstream for this package, letting it fall back
to the gbp-synthesized upstream/... tag.

/Simon

Attachment: signature.asc
Description: PGP signature

Reply via email to