Re: git-pull and tag objects

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 10 Feb 2007, Theodore Tso wrote:
> 
> This brings up another question which I've been looking for, but for
> which I haven't found a good answer in the git documentation.  A
> google search shows a suggestion by hpa (and a brief discussion from
> sct) about how to handle conflicting tags back in 2005, but as far as
> I can tell it didn't go anywhere.

I don't think we've ever had a conflicting tag.

> 1) Suppose I do a "git tag" of a release, and then realize that I
> messed up, and I need to do some additional release work (i.e.,
> editing a debian changelog file, etc.) before really doing another
> release, what do I do to tag a later revision as the "real" version
> v1.2?

Well, if you never pushed anything out, just re-tag it. Use "-f" to 
replace the old one. And you're done.

But if you have pushed things out (or others could just read your 
repository directly), then others will have already seen the old tag. In 
that case you can do one of two things:

 - The sane thing.

   Just admit you screwed up, and use a different name. Others have 
   already seen one tag-name, and if you keep the same name, you may be in 
   the situation that two people both have "version X", but they actually 
   have _different_ "X"'s.

   So just call it "X.1" and be done with it. 

 - The insane thing.

   You really want to call the new version "X" too, _even_though_ others 
   have already seen the old one. So just use "git tag -f" again, as if 
   you hadn't already published the old one.

   HOWEVER!

   Git does *not* (and in my very very strong opinion, MUST NOT!) change 
   tags behind users back. So if somebody already got the old tag, doing a 
   "git pull" on your tree shouldn't just make them overwrite the old one. 

And I really think that git does the right thing. If somebody got a 
release tag from you, you cannot just change the tag for them by updating 
your own one. I think this is a BIG security issue, in that people MUST be 
able to trust their tag-names. If I got a particular tag, NO WAY IN HELL 
must git just replace it for me because you happened to have a newer one!

So if you really want to do the insane thing, you need to just fess up to 
it, and tell people that you messed up. You can do that by making a very 
public announcement saying

  "Ok, I messed up, and I pushed out an earlier version tagged as X. I 
   then fixed somethign, and retagged the *fixed* tree as X again.

   If you got the wrong tag, and want the new one, you'll have to delete 
   the old one and fetch the new one:

	git tag -d X
	git fetch origin X

   to get my updated tag.

   You can test which tag you have by doing

	git rev-parse X

   which should return 0123456789abcdef.. if you have the new version".

Does this seem a bit complicated? HELL YES. But it *should* be. There is 
no way in hell that it would be correct to just "fix" it behind peoples 
backs. People need to know that their tags might have been changed.

> 3) The git-tag man page talks about GPG signing tags, but it doesn't
> talk about how a GPG-signed tag is validated.  Does this happen
> manually or automatically?

Use "git verify-tag X" to see something like this:

	[torvalds@woody linux]$ git-verify-tag v2.6.17
	gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB
	gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>"

but you obviously need to have the public key in question available to 
you.

We could verify tags automatically, of course, but the question is, what 
would the policy be? 

(Side note: the 'monotone' people do the trust thing very deep in 
monotone, AND IT IS A COMPLETE DISASTER! I'm surprised they are not only 
continuing with it, they are adding more and more infrastructure exactly 
because once you do it automatically, you need to be able to handle any 
possible policy. It's insane. It's also really sad, because monotone gets 
so many things right. Their security model is just *totally* broken, and 
makes the whole thing be just a steaming pile of shit. Sad. Not that the 
whole C++/boost/STL crap exactly "helps" either, but the security thing 
is probably the more fundamental problem.)

			Linus