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

-

[ message continues ]

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

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.

Now, I personally think you'd be better off just having separate names, 
but for something like a "passed testing" tag, it might be valid to (a) 
have the last one and (b) have a history chain. And it's not like it would 
be technically "hard" to do.

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?").

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

So _generally_ I think we're better off keeping things the way they are, 
but on the other hand, if only to work well with idiotic systems that 
mis-use tags in ways that tags shouldn't be used, we *could* just extend 
on what tyou can do with a git tag too..

		Linus
-

[ message continues ]

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


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.


-

[ message continues ]

Hi,


I don't think it is misusing the parent field, but I would make the 
primary parent the ancestor in terms of testing. In a very real sense, 
this maps the history -- not of development, but of testing. It also makes 
sense to bisect on this line of history.

The chance of a mismerge is somewhat real, though. At first I thought that 
you'd need a special script anyway, until I realized that it's just a 
matter of "git merge -s theirs <from-devel>".

Ciao,
Dscho

-

[ message continues ]

In fact, it's even quite doable as

	git commit-tree theirs^{tree} -p HEAD -p theirs < changelog

(choose your parent order at will) so it's not as if it's much of a 
"script". It's a core command to do something like this.

Using "git commit -s theirs" might not work (shouldn't, but I didn't test) 
for the first entry, so you probably *do* want to script this regardless. 
But git makes it really really easy.

		Linus
-

[ message continues ]