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"):
> 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]
I'm not sure I completely understand the situation.
> 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).
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.
> Maybe debpush could check that:
> - the tag version matches the changelog version
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.
> - the tag is actually on the active branch (or the one selected with
> --branch)
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.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
