I got this error:

jas@kaka:~/dpkg/git2cl$ git debpush --gbp --tag-only
tags upstream/3.0, v3.0 all exist in this repository
tell me which one you want to make an orig.tar from: git deborig --just-print '--version=1:3.0-3' TAG
git-debpush: git-deborig failed; maybe try git-debpush --upstream=TAG
jas@kaka:~/dpkg/git2cl$

The message is correct, but I don't understand why it is confused by the
unrelated v3.0 tag.

jas@kaka:~/dpkg/git2cl$ cat debian/gbp.conf
[DEFAULT]
debian-branch   = debian/latest
upstream-branch = upstream/latest
pristine-tar    = True
jas@kaka:~/dpkg/git2cl$

I thought gbp defaults where to use upstream/* so v3.0 doesn't match here:

Simon Josefsson writes ("Bug#1105759: git-debpush upstream tag confusion"):
...
...

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.

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.

Ian.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Thanks for explanation!

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?

Sorry if my questions/reports are silly, I try to not want/need to
understand any of the internals of how tag2upload works to simulate a
dumb user.

/Simon

Hello,

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?

I don't think so -- in every case where we might get something out of
pristine-tar we can instead get it from the archive, and the latter is
preferable.

Sean Whitton writes ("Re: Bug#1105759: git-debpush upstream tag confusion"):

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.

Ian.

Sean Whitton writes ("Bug#1105759: git-debpush upstream tag confusion"):

In principle the t2u service could support pristine-tar somehow.
I am not keen on that, for three reasons:

1. pristine-tar is a grievous hack.

2. When we're working in git, and from upsgtream git, as we should be,
pristine-tar's whole purpose (reusing upstream tarballs) is an
archaism.

3. Actually making this all work with pristine tar commits encoded in
the t2u tag etc. etc. would be distinctily nontrivial.

Ian.

Hello,

True.

Yes, that would make sense, but it would probably help only a minority
of cases.  You create the upstream/NN tag because the vNN tag doesn't
point to the right place (e.g. you've done an gbp import-orig on top of
it).

This is not very useful, because the tags format is an intrinsic
property of the repository and hence it should come with the repository
itself: or else users would need to set it every time a source package
is cloned.

Until we will have a more neutral standard mechanism to declare this
kind of things then I think that git-debpush and git-deborig using
debian/gbp.conf would help a lot since many packages use it.

Or else invent something for debian/source/ and persuade the gbp
maintainer that it's a better idea than gbp.conf...

Marco d'Itri writes ("Re: Bug#1105759: git-debpush upstream tag confusion"):

I think you are pointing out that the tag format is a property of the
upstream project and should be represented in-tree.  Since there isn't
an upstream standard, we should havwe a standard in debian/.

And...

... that gpb.conf is that standard.

This might involve a dependency on git-buildpackage so that we can run
gbp-config.  I doubt we want git-debpush to pull in the
git-buildpackage package.  git-buildpackage has a *lot* of
dependencies.

Maybe gbp-config could be factored into its own package or we could
reimplement its algorithm.  We should possibly consult with the gbp
maintainer.

Ian.

Hello,

I think the implementation would actually want to be in git-deborig over
in devscripts, but the dependency problem still applies.  I'll write to
Guido suggesting the split.

Hello Guido,

In #1105759 we have been discussing whether git-deborig, which is
invoked by git-debpush, could read the upstream tag format out of
debian/gbp.conf.  Currently it tries several possibilities and fails if
more than one of these tags exists, or if none of them do.  In those
cases the user has to supply the full upstream tag name.

We'd want to do this by invoking gbp-config.  But adding a dependency on
the whole of gbp is undesirable, because that pulls in loads.  While
currently most users of git-debpush probably already have gbp installed,
we are hoping that git-debpush can be used for things like mass
source-only uploads in minimal environments, and the like.

What do you think about breaking gbp-config out into its own binary
package?

Thanks.

Hi Sean,

That would work form me (and we've had other situations where that would
be useful in the past). `gbp config` (as all other subcommands) depends
on classes from the `gbp` module so we'd need to split out the minimal
subset there too to get a smaller set of dependencies (we do something
similar for the git-buildpackage-rpm to not have `git-buildpackage`
depend on rpm tooling). A simple autopkg test would make sure that we
don't break this on refactors.

Cheers,
 -- Guido

Guido Günther writes ("Re: breaking gbp-config out into a separate binary package"):
the improvements we want.


I just wanted to share with you an alternative suggestion we received:

Marco d'Itri writes ("Re: Bug#1105759: git-debpush upstream tag confusion"):

I guess you think it would be better for us to Depend on a split-out
gbp-config, than to reimplement the parsing using some INI file
reader (in a Perl library maybe).

So, I think you would recommend against that alternative
reimplementation approach.  Am I right about that?

Ian.

Another argument in favour of an in-tree representation of the tag
format is that it can change over time.

Hi,

Works as well but that means you'd have to track any possible changes in
the format - it's not supposed to change much but `gbp-config` would
know about it automatically.

Cheers,
 -- Guido

retitle -1 want git-debpush to read upstream tag pattern from gbp.conf

Hello,

In #1105759 we are discussing how git-debpush could get upstream tag
information out of debian/gbp.conf.  Ian and I are talking about this,
and we realised that git-debrebase could benefit from this functionality
just as much as git-debpush.

After talking about how to do that we came to the conclusion that the
most sensible thing is to add this functionality to git-deborig itself.

Then, in order to fix #1108181 at the same time, we would like to move
git-deborig from bin:devscripts to bin:git-debpush, have bin:git-debpush
no longer depend on bin:devscripts, and finally have bin:dgit and
bin:git-debrebase depend on bin:git-debpush.

I'll do that once we've released trixie.

Hi,

I ran into this same issue today:

± git-debpush --gbp
git-debpush: found upstream tags: v0.1.0 upstream/0.1.0
git-debpush: use --upstream=TAG to say which one to use

Based on Ian's reply to Simon, the "upstream tag" that
git-debpush/git-deborig is looking for is the tag git-buildpackage put
on the commit that represents the upstream import.

I support the idea here of reading the gbp.conf. Basically if --gbp is
given to git-debpush, it could pass --gbp along to git-deborig, which
could understand it should check debian/gbp.conf:upstream-branch and
based on it pick the same tag git-buildpackage would use, in this case
'upstream/0.1.0'.

Thanks for working on this gbp-compatibility feature. In the meanwhile
I will just manually run:

± git-debpush --gbp --upstream=upstream/0.1.0


PS. This bug also discusses pristine-tar support. That is now in
progress via Bug#1106071 in case other people who read this bug report
were not aware of it.

Andrea Pappacoda writes ("Bug#1139658: git-deborig: should look for tag without 0_ prefix"):

So, just to make sure I have understood correctly:

In this package upstream do make tags, but their tags are named things
like `20260423`.  In Debian we have the `0~` for the reasons you
describe.  What you ask is for git-deborig to guess this upstream tag
format in this situation.

I think this is probably too unusual to special case.  Often such a
0~ means there's no upstream at all.

Instead, I think this should be handled as follows:

 * Somewhere in the git tree's debian/ directory there should be a
   config file that specifies the tag convention.

 * git-deborig (and git-debpush and other tools) should honour it.

Currently both uscan and gbp have separate config files for this.

So, in summary, I think this would be fixed by a fix to #1105759,
CC'd.

Ian.

Hi Ian,

Yes.
<https://lintian.debian.org/tags/new-package-uses-date-based-version-number.html>.

Still, it's nowhere near as common as the "v" prefix for version
numbers, so it's fair not to special case this.

That makes more sense! I guess you are talking about gbp-import-orig's
upstream-vcs-tag option, but I don't get the uscan reference (maybe you
mean d/upstream/metadata?).

Feel free to close or merge this bug :)

Andrea Pappacoda writes ("Re: Bug#1139658: git-deborig: should look for tag without 0_ prefix"):

That's something subtly broader.  That lint covers also cases where
upstream don't make tags at all.  TBH, I don't have a strong feeling
about a special case for this, but I think we should focus our efforts
on the general solution:
...

Yes, in gbp, upstream-vcs-tag.  Weirdly, gbp import-ref doesn't seem
to support it.  (As you know, in our opinion, one should generally not
use gbp-import-orig, common practice in Debian notwithstanding.)

In uscan this is
  mode=git
  matching-pattern=refs/tags/...

Ian.