Problems with deleting tags?

[Richard Wilbur]

On Sat, Apr 16, 2016 at 11:13 AM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> Richard Wilbur writes:
>
>  > Do we improve things if we make tags version controlled?
>
> It should improve the "immortal tags" situation.

That sounds useful.

> The tags file will
> rarely change, and the usual algorithms for merging will apply.  Most
> likely conflicts might be add/add.

This makes it sound not too challenging.

>  > 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.

Looks like the current spot is .bzr/branch/tags as of bzr 2.7.0

> 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.

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.

> 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).

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.

> 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.

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'?

> Steve

Thanks for sharing your thoughts, Steve.