Re: newbie questions about git design and features (some wrt hg)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 2, 2007, 19:42 UTC
Message-ID: <Pine.LNX.4.64.0702021130020.15057@woody.linux-foundation.org>
In-Reply-To: <20070202192640.GA7963@ventoux.cs.ubc.ca>

On Fri, 2 Feb 2007, Brendan Cully wrote:

Show 12 quoted lines

> 
> I don't think I do, no. (Maybe it's the double negative construction.)
> Local tags don't get pushed. Tags on private branches don't get
> pushed. Tags on public branches do. This business you describe, where
> you push tags around completely separate from the revisions they tag,
> sounds a little odd. But nothing stops you from maintaining your local
> tags in their own repository, if that's what makes you happy.
> 
> > In other words, tags are just like branches. You don't tie two tags 
> > together, because one may (and does) make sense without the other.
> 
> Which tags are being tied together?

If you tie "tag" together with "history", and push out history, what happens?

> It seems to me they clearly do have history.

No they don't. Quite often, tags are generated outside of history, ie you tag something as being "known bad" long after it was done. Or you (hopefully) tag it with the test-information after it passed (or didn't) pass some debug check. Neither of which is something you'd do when the thing is actually committed or developed.

So tags are *events*. But if you think they are events "within" the history of a tree, you're missing a big issue.

My personal use of tags tends to be
 - I tag releases I make, and sign them etc.
 - when debugging (and using "git bisect" in particular), I tag things for 
   my own memory (ie if a bisection selected something that didn't 
   compile, and I have to pick another point by hand, I tag that bad one 
   temporarily for explanation - the tag shows up nicely in the graphical 
   history viewers)

The "release" tags are done as I develop, since _others_ will do regression tests etc later on. I don't know whether those others will add their own tags on top of my tag ("passed-regression-test" tag that points to my release-tag, which points to whatever commit I released), but it's really worth pointing out that that is just a small special case.

That *small* special case I wouldn't mind being part of history. But all the other tags should never be, since they are actually personal to whoever made them (even though others may well care: for example, if a regression run tags something as "passed", a lot of people will care: it doesn't mean that the tag should be entirely private!).

And because it's wrong in general to make the tags be bound to history (because they may or may not be relevant to others, and they may or may not actually happen _during_ the history), it's wrong to design the tags that way. Tags really are "outside" the thing, unless you live in a world where only the lead engineer is supposed to use tags.

I want tags to be useful for *anybody*. A total non-developer, who decides that he wants to test a release, should be able to tag the particular versions he happened to test, and it damn well shouldn't be just "my-tag-1023". It should allow him to write a small story about what the results of the tests were!

Which is how git tags are desiged. They're separate from history, but that doesn't make them less useful - it makes them *more* widely useful.

		Linus