On Sat, Aug 22, 2020 at 01:56:00PM +0200, Hilmar Preuße wrote: > >> The person who did the upload for debian/0.7+git73896501cf-1 did not > >> update the "upstream" branch, hence the tag was not created. Actually, the person who did the "Upgrade to latest commit from github." (92ff447) commit in 2018 didn't do that, as that commit changes the upstream sources in the master branch directly instead of updating them in the upstream branch and merging. > > The tag creation dates are irrelevant. > > In the gbp workflow the merge order is not relevant either as long as the > > upstream tag content is correct. > > > Not sure about this statement, b/c this was finally the solution: (the statement is correct as it doesn't talk about gbp push, I assumed the problems are not specific to it) > - delete the debian/... tag locally and remotely > - run again "gbp tag" and "gbp push" So it looks like you were trying to push the things that were already in the remote repo? Then it's indeed not supported by `gbp push` in your case: "Determine if the tags correspond to the branch tips of the corresponding upstream and debian branches. If so, these branches will be added to the list of things to push. If not the changes will only be pushed up to the commit that is referenced by the corresponding tag." So it was trying to push the commit that was tagged as debian/0.7+git73896501cf-2 to master while remote master contained additional commits on top of that one (speficially, the merge commit). Note that if you delete a tag, create a new one with the same name and publish it, nobody who cloned the repo before that will know about it, they will still have the old tag unless they delete it locally too, and `git fetch` and `git pull` will not tell them that the tag was updated. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature