Problems with deleting tags?

[Stephen J. Turnbull]

Richard Wilbur writes:

 > The git reflog certainly appears ephemeral--the referenced page
 > doesn't describe a way to create a reflog entry.  It only discusses
 > commands to show, expire, or delete entries.

Ah, sorry: every time a ref is changed (other than commits to a
branch), the change is implicitly logged.  That means moving a tag,
rebasing a branch, etc are logged, but normal extension of a branch
with new commits is not.  It's easy enough to imagine this being
applied to a log of explicit tagging actions, I think.

 > If we implement version-controlled tags via applying our normal
 > version-control strategy to a file specifically for tags, it seems
 > that we will likely introduce a few similar situations.  At the moment
 > one comes to mind:  Changes to .bzr/branch/tags could end up under a
 > different tree revision id than that to which the changed tag refers
 > if they aren't carefully implemented.

I'm not sure what you mean, but in particular in Mercurial revids are
based on cryptographically strong hashes, so the tagged revid must be
different from revid of the tag (making them be same is a fixed point
problem in an unpredictable space! :-)

It might be possible to treat that file specially so that the current
tagged revid is somehow added after the revid is computed (something
like the way DKIM email headers sign themselves except for the hash
value itself), but it's probably too complicated to be worth it.

 > Any ideas on how to avoid polluting other branches with ephemeral or
 > personal tags?  Maybe we create them by default as branch-local unless
 > you specify a command line flag like '--global'?

That is what I would have suggested offhand, but I've given it no
thought.

Steve