On Thu, Mar 20, 2025 at 3:59 PM Guido Günther <a...@sigxcpu.org> wrote: > 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.
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
