control: tag -1 + wontfix Hello,
Simon Josefsson [08/Feb 11:09am +01] wrote:
> 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.
This is impossible because without a tag we can't guarantee that the
commit is actually fetchable.
The recommended thing to do here is create an upstream/foo tag yourself.
--
Sean Whitton
signature.asc
Description: PGP signature
