In my first attempt to use tag2upload I was very confused because it
kept trying to push an old tag on the debian/unstable branch instead of
the one on the debian/experimental branch that I was working on.
Even after adding --branch=debian/experimental:

$ git debpush --dry-run --print-tag-text --upstream=varnish-7.7.1 --branch=debian/experimental --quilt=gbp
varnish release 7.7.0-3 for unstable

[dgit distro=debian split --quilt=gbp]
[dgit please-upload source=varnish version=7.7.0-3 upstream-tag=varnish-7.7.1 upstream=2e8180f788715e5bc44df08479d60c9435d79bdd]

After a lot of wasted time and attempts, I figured out that I had forgot
to commit the new changelog (I like to have a clean history and commit
a single complete changelog along with the release tag).

Maybe debpush could check that:
- the tag version matches the changelog version
- the tag is actually on the active branch (or the one selected with
  --branch)

Hi.  Thanks for the report.  We want this tooling to be easy to use,
and to help spot mistakes, so we appreciate the feedback.

FTR Sean is the UX lead for git-debpush but I have some thoughts:

Marco d'Itri writes ("Bug#1108088: should check that the changelog version matches the tag version"):

I'm not sure I completely understand the situation.

I think you are saying that:

 * You had intended to upload to experimental, from a local git branch
   called debian/experimental.
 * Your practice is to create the whole d/changelog entry for an
   upload immediately before upload.  So prior to that point,
   the changelog is the same as for the previous upload.
 * You had not (yet) done that for this upload, due to an oversight.
 * Your git tree was clean.
 * Your current branch was debian/unstable, which contained some
   other work which is not germane.  This was also an oversight.

Then you ran git-debpush --print-tag-text and got some kind of error
or unexpected behaviour.  You write "trying to push an old tag", but
maybe you mean "trying to re-upload an old release"?  git-debpush
won't ever push non-tag2upload tags.

To try to resolve the problem you ran git-debpush with an additional
option --branch=debian/experimental.  This also produced different
output which was in some way unexpected.  Perhaps the discrepancy is
that its upstream version tag name and the Debian version don't match?

(A shell transcript would have been very helpful.)

Did you have the debian/7.7.0-3 tag in your tree?  I think git-debpush
should complain if it finds an existing DEP-14 tag for the version it
is trying to upload.  (Ideally it would look both in your local tree,
and on salsa via the initial fetch proposed in #1107921.)

So if one forgets to update the changelog, or tries for any other
reason to repeat an existing upload, that would be detected.

I'm not sure what you mean by "the tag version".  Do you mean the
upstream tag you specified on the command line?

If so I think that might involve git-debpush trying to parse the
supplied upstream tag name to try to guess if it looks "enough like"
the upstream part of the version being uploaded.  This seems fraught
with difficulty.

I think git-debpush could check that the commit you are trying to
upload is fast forward from the nominated upstream (except with
--quilt=baredebian).  Maybe it already does check this.  But I think
that wouldn't have helped here.

What did you expect --branch to do ?

AIUI it's intended use case is precisely to upload from a branch you
don't currently have checked out.  I think this is a minority
interest.  Maybe it should have a less attractive name.

Ian.

No, the current branch was debian/experimental.
debian/unstable was fine, it just contains releases which have already
been uploaded.

I was at f34d2997e77afc729b162041c0c511e5c5b41594 of
https://salsa.debian.org/varnish-team/varnish/ .
Yes.

In other words, adding --branch=debian/experimental had not effect and
debpush was still proposing to create a tag on debian/unstable:

md:.../varnish debian/experimental(+27/-0)± git debpush --dry-run --print-tag-text --upstream=varnish-7.7.1 --quilt=gbp
varnish release 7.7.0-3 for unstable

[dgit distro=debian split --quilt=gbp]
[dgit please-upload source=varnish version=7.7.0-3 upstream-tag=varnish-7.7.1 upstream=2e8180f788715e5bc44df08479d60c9435d79bdd]
md:.../varnish debian/experimental(+27/-0) 1± git debpush --dry-run --print-tag-text --upstream=varnish-7.7.1 --branch=debian/experimental --quilt=gbp
varnish release 7.7.0-3 for unstable

[dgit distro=debian split --quilt=gbp]
[dgit please-upload source=varnish version=7.7.0-3 upstream-tag=varnish-7.7.1 upstream=2e8180f788715e5bc44df08479d60c9435d79bdd]
md:.../varnish debian/experimental(+27/-0)±
Yes, it was and still is in the debian/unstable branch (and on salsa).
No, I meant to check that the tags that it creates and is trying to push
matches the current version of the changelog. But my problem was that
the changelog version on disk was different from the one in the
repository (because I forgot to commit the changes), so probably there
is nothing that debpush can/should do about this.
OTOH I do not understand why it just did not fail since debian/7.7.0-3
already existed. Maybe --dry-run skips this check.
debian/experimental too and it matched the last changelog entry in the
repository.

In the end I am not sure anymore that there is much actionable here,
except figuring out why --dry-run did not detect the existing tag.

Marco d'Itri writes ("Bug#1108088: should check that the changelog version matches the tag version"):

Right.  git-debpush looks at debian/changelog to decide what to do.

So your git tree was dirty?  You had edited d/changelog but not
committed?  I'm surprised that git-debpush didn't object to this
situation...

... but it turns out it doesn't check for this.  And it does its work
in a little private tree where it sees only committed git objects, so
it carried on in blissful ignorance.

Gosh.  Well, we will fix that.  Thanks for the report!

I think there are several things about your situation nwhere
git-debpush could have done better:

1. It ought to complain if your git tree is dirty.  That nearly always
means you forgot to commit.  In this case that meant it used the
version of d/changelog in HEAD rather than the one in your working
tree, which is definitely wrong.

(This bug, #1108088.)

2. I think maybe --branch ought to be called --other-branch or
--upload-other-branch or --look-only-at-other-branch or
--other-git-branch or something.  Just --branch is too attractive a
name.

A user who is confused may use it in an effort to correct an apparent
misbehaviour, but in such a situation it's likely to make things worse
rather than better.  (In your case it did nothing.)  Some gbp tools
have --branch options which are much less exciting.

Another awkwardness with --branch is that some people might think it
referred to the target Debian release.  (Eg when the BTS says "from
other branch bugs".)  We call that a "suite".  This option is about
the local branch to use as input, not where the output ends up.

Let's see what Sean thinks about this.  (Bug clone -2, bug# TBD.)

3. git-debpush ought to avoid re-making an existing DEP-14 tag.
This is covered by #1107921, especially
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107921

I'll write more there.

Ian.

Hello,

Marco, do you think if it had been called "--other-branch" or
"--upload-other-branch" that would have meant you didn't try it?

I think that the --branch name is quite clear and it does exactly what
I expected it to do.

Hello,

Thanks.  Given this feedback, I'm not sure we should monkey about with
the name.  We can wait and see what other user's experiences are.