Problems with deleting tags?

[Stephen J. Turnbull]

Richard Wilbur writes:

 > Do we improve things if we make tags version controlled?

It should improve the "immortal tags" situation.  The tags file will
rarely change, and the usual algorithms for merging will apply.  Most
likely conflicts might be add/add.

 > My understanding of tags is probably incomplete but it at least
 > connotes creating a name for a snapshot of version information.  What
 > would it mean to make tags version controlled?

Since a tag basically associates a name with a fixed version,
version-controlling would mean a version-controlled special file
containing a list of (tag, revid) pairs.  Mercurial, for example, puts
it in .hgtags as a sibling of the .hg directory.  I would prefer to
put it in .bzr/tags, but there may be a reason not to do that.

I suppose the features would be similar to the git reflog (but git's
reflog is intended to be ephemeral, rather than a true recording of
versioned information -- you can probably ignore all discussion of
expiration).

https://git-scm.com/docs/git-reflog

I'm not sure that will be helpful, I'm too tired to recall what git
jargon is different from bzr's.

Mercurial's implementation has some warts in my opinion.  It increases
the noise in the logs, since a tagging operation involves a commit.
In the log the tag can show up far away from the commit tagged, and
even on a different branch of the DAG, which is disconcerting
(although it doesn't affect the use of the tag, which is accessed via
the .hgtags file, not the version history).

There's also a problem that many tags really are ephemeral or
personal.  I use tags a lot for error recovery when rebasing or even
just a normal pull in a branch that hasn't been updated, to "close" a
branch that has been merged to another while preserving its name, and
so on.  Most of these tags have no meaning to anyone but me, and some
don't even have meaning to me 10 minutes later.

Steve