Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 28 |
Nodes: | 6 (0 / 6) |
Uptime: | 54:13:56 |
Calls: | 422 |
Files: | 1,025 |
Messages: | 90,666 |
Simon Josefsson writes ("Bug#1105759: git-debpush upstream tag confusion"):
Package: git-debpush...
Version: 12.12
Severity: wishlist
The message is correct, but I don't understand why it is confused by the...
unrelated v3.0 tag.
I thought gbp defaults where to use upstream/* so v3.0 doesn't match here: >>
--upstream-tag=tag-format
Use this tag format when tagging upstream versions,
default is upstream/%(version)s.
git-debpush doesn't read gbp.conf nor does it invoke gbp.
I don't think we want it to do either.
So making this work like you want isn't going to be very easy.
Maybe we could talk to the gbp maintainer and ask if there could be a
common *git* config option (set with `git config`) for this question. git-debrebase needs this information too since it also finds upstream
tags. As does git-deborig.
FWIW, this is a really nit-pick user experience bug report -- feel free
to close if it is hard to solve. The workaround is trivial:
git debpush --gbp --tag-only --upstream=upstream/3.0
Right.
Thanks for the report. This is precisely the kind of thing we would
like to make nice and smooth. It's a shame that this particular one
doesn't seem easy.
git-deborig has had this behaviour for a long time and it might be worth revisiting it. Perhaps it is being too cautious: perhaps it should
always prefer an upstream/NN tag to NN or vNN if there is an upstream/NN present. How about that?
Btw, this upload resulted in a failure because the orig.tar SHA256
checksum failed to match what's in the archive. Presumably
'git-debpush' computed a different orig.tar file than was in the archive
and also was in the pristine-tar branch.
Is a 'git-debpush --pristine-tar' relevant?
Sean Whitton writes ("Re: Bug#1105759: git-debpush upstream tag confusion"):
git-deborig has had this behaviour for a long time and it might be worth
revisiting it. Perhaps it is being too cautious: perhaps it should
always prefer an upstream/NN tag to NN or vNN if there is an upstream/NN
present. How about that?
This seems contrary to the key principle that it is better to stop
with an error, doing nothing, than to risk doing the wrong thing.
We could check if these tags all refer to the same commit.