Andreas Ericsson <ae@xxxxxx> writes:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html