This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deleting git tags?


> Are we disallowing tag deletion because it's akin to
> rewriting history?

We have not really decided on policies for these things and reasons why.
Jim set up the hooks and knows the rationale for their settings, but those
are just generic notions coming from other projects.

> The problem I have with that is that tags are used for
> logical purposes, and mistakes show up in the tag list.
> Mistakes in a commit are quickly lost in the logs but
> not so for tags.

Sure.  But by the same token, mistaken commits are part of the history and
are easily reverted because the history before and after is all there.
Addition or removal of a tag doesn't enter the permanent history in the
same way.  If you remove a tag and I wish you hadn't, then there is nothing
in the shared repository that preserves the information.

> We should be allowed to manage tags as we like to keep
> the list clean.

Anybody with shell access to sourceware (like me) can do it.  Not being
able to do it remotely might be considered a feature, since it prevents
every committer from potentially erasing things accidentally.  OTOH, when
someone cares about a tag they probably will have pulled it into their
local repository and thus can always push it back up later.

> The only other problem is that users have to manage
> keeping their local tags in sync with the remote repo,
> but that's a question for another day (there are scripts
> for doign this).

Unless and until such tag management is well-integrated into the core git
commands, I think we should consider it an undue burden for people to be
expected to remove tags locally with any regularity.  Thus I think we
should keep the creation of tags sufficiently rare for now that the
likelihood of wanting to delete one is quite rare.

The other double-edged sword with annotated tags (-a or -s) is that they
form the set of default bases for 'git describe'.  When 'git describe'
produces 'glibc-2.15-1213-ged3dbfa', that is pretty useful.  When it
produces 'glibc-2.16-tps-1-ged3dbfa' that seems less useful.  When it
produces 'roland/silly-tag-du-jour-22-ged3dbfa', that is far less useful.

As Thomas pointed out, for miscellaneous marker-dropping purposes, you can
always just use branch names in your private name space, and choose names
sufficiently unique that you're not going to reuse the same name later.
That doesn't have the benefit of 'git describe' using those names as bases.
But it does have the benefit that 'git remote prune origin' cleans up old
copies of such branch names that their creator has since removed.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]