Re: git-tag bug? confusing git fast-export with double tag objects

From: Junio C Hamano <gitster@pobox.com>
Date: May 15, 2009, 17:40 UTC
Message-ID: <7v3ab6uuw4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4A0D9696.1040805@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 11 quoted lines

> Is it? Does it really make sense to have a tag named "foo" point to a tag object
> that in turn points to a tag object without a tag ref? I mean, if you're signing
> a tag, it makes sense to want to keep the original tag around so people can
> reference it. If you want to *replace* a tag, it doesn't make sense to create
> this chain which, iiuc, goes something like this:
>
>   tag ref -> tag object -> tag object without ref -> something
>
> Honestly, I can see how this turned out to be confusing, as you end up with a
> tag object without a tag, but a new tag in its place. Not to mention that the
> new tag won't be push-able without --force in case the old tag was pushed earlier.

Suppose the gpg key used to sign v1.6.3 somehow gets compromised, and I come up with a new gpg key. I could reassure people that the commit the old v1.6.3 tagged is genuine if I re-tag with the new key like this:

	git tag -f v1.6.3 v1.6.3^{commit}

But what should I do if I would want to reassure people that both the old v1.6.3 was tagged by _me_ (with the old key that later was compromised) and that the commit that old tag tags is genuine?