Re: git-pull and tag objects

From: Junio C Hamano <junkio@cox.net>
Date: Feb 14, 2007, 07:22 UTC
Message-ID: <7vfy99td98.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0702132230490.3604@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 7 quoted lines

> 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.

Show 9 quoted lines

> 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.

Show 5 quoted lines

> 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.