Deleting git tags?

[Thomas Schwinge]

Hi!

On Tue, 26 Jun 2012 14:56:13 -0400, Carlos O'Donell <carlos@systemhalted.org> wrote:
> Last night I created several tags in both the core
> and ports repos to mark the commits at which the
> libc.pot file was sent to the translation project.
> 
> Since then we've talked about what to call these
> tags to avoid confusion.
> 
> Given that I haven't uploaded a 2.15.1 snapshot
> for the translation team I decided I would delete
> these tags and follow the new naming convention.
> 
> I've delted the glibc-2.15.1-tps tag from the ports
> repsoitory with no problem.

(This won't delete the tag for people who had since pulled from the
sourceware repository.)

> However, deleting the remote branch on the core repo
> results in:
> 
> carlos@lios:~/src/glibc-2.15$ git tag -d glibc-2.15.1-tps
> Deleted tag 'glibc-2.15.1-tps' (was 88f501d)
> carlos@lios:~/src/glibc-2.15$ git push origin
> :refs/tags/glibc-2.15.1-tps
> remote: *** Deleting a tag is not allowed in this repository
> remote: error: hook declined to update refs/tags/glibc-2.15.1-tps
> To ssh://carlos@sourceware.org/git/glibc.git
>  ! [remote rejected] glibc-2.15.1-tps (hook declined)
> error: failed to push some refs to
> 'ssh://carlos@sourceware.org/git/glibc.git'
> 
> Are we disallowing tag deletion because it's akin to
> rewriting history?

I assume that it's because of the write-once property, so there is no
coherent action what is going to happen in peoples' repositories in such
a case -- it depends on the individual pulls' timing.  See also the
discussion »On Re-tagging« in »git tag --help«.

I do agree that glibc and glibc-ports should be configured in the same
way.  (CCing Jim Meyering for this purpose, who has been configuring the
Git repositories, if I remember corrently.)  For the reasons given, I'd
lean towards disallowing the deletion of tags.  (And, on a similar topic,
I do not agree with the configuration of disallowing (forced) non-forward
pushes to branches (apart from "official" master and other release
branches maybe) -- an equivalent thing can always be achieved by the more
destuctive »git push [remote] :[branch]« followed by pushing anew.)

> 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.
>  
> We should be allowed to manage tags as we like to keep
> the list clean.

Again, not possible.  That's why I discourage the use of tags.

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

What exactly do you mean here?


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120626/2d66c65d/attachment.sig>