Junio C Hamano wrote:
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?
Add a tag with a new name, pointing to the original tag. Try doing what
Matthias did and then run "git show $tagname". It won't show the original
tag at all, so people have to resort to low-level commands in order to
see it, but it will still exist as an object.
The main point though is that re-creating a ref with different content
adds major headaches when distributing it. People who have the old tag
and fetches from a new repo won't get the new tag stored in a ref. If
the object is transferred, it will be garbage-collected.
So let's examine the scenario you described, with your gpg key being
compromised.
You re-create all your tag refs with same-name tags that point to the
old tags.
Joe Dev fetches from you, but your tags do not get stored as refs.
Joe Dev publishes a repo somewhere with a bunch of topic-branches and
requests you merge from those repositories.
You fetch from Joe.
Now we have two opposite problems.
If tags aren't updated when Joe Dev fetches from you, his refs will
not match yours when you fetch from him, and anyone cloning from him
even after the re-sign will never get the new tags at all.
If tag refs *do* get updated when fetching from a repo when we already
have another tag ref with the same name, you fetching from Joe Dev
could undo all your re-created tags and make the new tag-objects
garbage-collectable. This assumes Joe Dev published his repo before
fetching your new tags though.
Perhaps I'm missing something. It's 9AM here and I woke up ten minutes
ago, but it seems to me that what will happen and what should happen
is not entirely clear when one creates tag refs that already exist and
are published.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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