Move tags while rebasing a branch?

[BatmanAoD]

I realize that tags are supposed to be quasi-permanent, but I have a use-case¹ for rebasing sequences of changes while keeping any tags on those changes associated with that change. That is, if A has tag T, and it changes as part of the rebase, I would like T to refer to A/0 rather than A/1.

Is this possible without just manually updating each tag after the rebase?

Footnotes

1. This is not necessarily a good or common use-case, but it is a use-case. Specifically, I use knope to make releases. Knope uses git tags to determine the most recent release. When working on a branch (i.e. a sequence of commits coming off of trunk() and terminating at a bookmark), I sometimes make a prerelease. For prereleases, Knope uses an auto-incrementing integer as part of the prerelease component. If I am working on a branch that does a feature bump, and I merge from main after there has been a patch release on main, then Knope doesn't take into account my prior prerelease tags, because it sees that there is a more recent release that is not an ancestor of the prior prereleases. So the simplest way to ensure that Knope keeps incrementing the integer from where it left off is to do a rebase, so that the prior prereleases are all after the latest full release. But this requires moving tags around. ↩

[jennings]

A tag that follows revisions as they're rewritten is a bookmark :)

Is there no way to make Knope release from a branch instead of a tag?

[BatmanAoD]

Wellllll, yeah, that's why it definitely shouldn't be a default behavior.

Knope uses git, not jj, so it creates a new commit on the current branch. The release-commit itself is tagged because that's how GitHub and GitLab identify "releases". And, consequently, that's also why knope uses tags to identify what releases exist so far.

[BatmanAoD]

I've started a discussion in the Knope repo about handling this, too: knope-dev/knope#1924