Suggestion: superceded tags

["H. Peter Anvin" <hpa@zytor.com>]

It's a pretty fundamental concept in git that objects in the object 
repository live forever.  This is key to distribution, and is a good thing.

However, for tag objects, this is somewhat awkward.  It is occationally 
necessary to move a tag (restarted release processes, being one reason); 
purists tend to frown on it but it's reality.

It would be nice to maintain that all tag information exists in the 
object database and loss of the .git/refs directory will not harm that. 
  Thus, I'd like to suggest the following protocol:

When a tag is moved, a new tag object is created.  This tag object will 
have a "supercedes" header which references the old tag object.

Say, for example, that tag "klibc-1.0.14", object 
4695b4d163b62f6a9860b9bbe06ff30edb6e02be, exists with the following 
contents:

object fdb8a185ef261568f01140989745b8636212db71
type commit
tag klibc-1.0.14

Now "klibc-1.0.14" needs to be moved to new commit 
088c166af39b1ca2712667c44dccd3c7af99a8fb.

The new tag object should thus look like:

object 088c166af39b1ca2712667c44dccd3c7af99a8fb
type commit
supercedes 4695b4d163b62f6a9860b9bbe06ff30edb6e02be
tag klibc-1.0.14

(I put "supercedes" before "tag", because unfortunately the tag header 
terminates immediately after the "tag" line without having an 
intervening blank line.)

This will make it possible to move the tag, but still to recreate all 
tag information from the object database alone.

None of this can of course help the conflict if the same tag is created 
in different places by different people, and then they are trying to be 
merged.  The above at least makes it possible to distinguish the case of 
a tag conflict with the case of a moved tag, and in the case of the 
moved tag, will stand out.

On the other hand, it makes it possible for more than one tag to exist 
with the same name pointing to the same object:

User 1 creates tag X referring to object A	-> T1
User 1 moves tag X to object B			-> T2
User 2 creates tag X referring to object B	-> T3

There is no conflict here, but T2 and T3 will be different objects (one 
will supercede T1, and the other won't.)  An object-database-scanning 
program should observe that T2 and T3 are consistent, and T1 is 
superceded, therefore tag X is well-defined; it can arbitrarily use 
either instance T2 or T3.

	-hpa