Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> On Mon, 12 Feb 2007, Junio C Hamano wrote:
>>
>> "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.
-
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