On Fri, 2 Feb 2007, Brendan Cully wrote:
>
> 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
-
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