Re: git-pull and tag objects

Linus Torvalds [off-list ref] writes:

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted

"fsck --full" should report "dangling tag".

Well, except if
 - you've pruned
 - the importer never imported anything but the most recent one.

True -- but Ted was talking about look for them in order to
eradicate them, so if you've pruned or never had one, you are
Ok.

One thing that _might_ be a good idea for tags (if people _really_ want to 
actually update tags under the same name) is to have a "parent" pointer 
for tag objects, the same way we have for commits. That way you could - if 
you really wanted to - create a chain of tags, and show the history of 
them.
...
I dunno. Personally I'd rather try to just tell people to not re-use 
tag-names, because it kind of destroys the whole point of a tag ("I 
checked out tag X!" just leadsto "_Which_ X?").

I agree.

And you could certainly do the "passed testing" thing with commits in a 
separate branch instead: you'd create the "testing" branch, which is 
always a set of commits that have as their primary parent the commit that 
got tested, and as the second parent the previous commit in the "testing" 
series).

I personally feel that that kind of commit is misusing the
parent field (for one thing, it would not play well with merges
at all, although people who abuse commits to record non-ancestry
structure may not even be interested in merging such things so
it may not be a problem in practice).  If people want to express
relationship between commits (and other objects in general)
other than ancestry, I think it would be cleaner to allow a tag
to have more than one pointers to other objects.

I know you are against arbitrary pointers inside objects that
does not have semantic meaning, and I agree.  Probably your
"previous version of this tag was that one" is better than "more
than one arbitrary pointers" in that sense.

But I do not know how useful a linear history of tags are; it is
semantically the same as v1.5.0, v1.5.0.1, v1.5.0.2, ... sequence.