Sometimes I forget to git pull before I gbp push. This is a problem if
I have tagged a release. gbp push pushes the git tags first and then
errors on pushing the branches.

I imagine if git-buildpackge could push the branches first and if the
branches fail, then it could intentionally not push the git tags.

This would make it easier to fix the situation locally without needing
to delete the erroneous git tag that has been pushed.

Thank you,
Jeremy Bícha

Hi,

This is already possible by setting the tag empty. See

https://salsa.debian.org/DebianOnMobile-team/dom-tools/-/blob/main/release-dom-component?ref_type=heads#L161

Updates to the documentation are welcome.
Cheers,
 -- Guido

This is a request for a better default, not for documentation. If
there is a problem pushing to one of the branches, there could be a
problem with a tag also. Therefore I would expect git-buildpackage to
not push the tag.

Thank you,
Jeremy Bícha

Hi,

I'd argue that pushing tags first *is* the better default as it ensures
tags become public if present. Once can always construct branches from
tags but not the other way round.

I might not understand your use case correctly. If the issue is that
pushing the same tag again fails than this should become idempotent
rather than switching the order.

(no idea how this got `-done` added to the address, ropening)

Cheers,
 -- Guido

Test Case 1
-------------
Contributor A pushes a release to debian/latest with a debian/1.0-1 tag
Contributor B pushes a commit to debian/latest
Contributor A prepares an update and pushes a release but forgot to
run git pull first. Maybe it's rare for other people to commit to this
repo.
gbp push. Now there is a debian/1.0-2 tag that will not be in the
linear git history of debian/latest

To fix that currently, we need to do something like
git push origin :debian/1.0-2    to delete that tag, hoping that
nothing already pulled that tag because git's workflow doesn't update
local tags by default
git tag -d debian/1.0-2
rebase locally, retag, then git push everything

My suggestion would eliminate the need to delete the remote tag since
it is never pushed.

Some git repos have more complex git commit histories. I prefer a
fast-forward style where each tag and commit on debian/latest is
linear (except for the merges from upstream/latest)

Thank you,
Jeremy Bícha