Suggestion: superceded tags

Suggestion: superceded tags

[H. Peter Anvin]

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

Re: Suggestion: superceded tags

[Stephen C. Tweedie]

Hi,

On Fri, 2005-05-27 at 06:29, H. Peter Anvin wrote:

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

Strictly speaking, don't you need to allow multiple "supercedes" lines
to cover all the cases?  The pathological case is when you've got
multiple trees all with different variants of the same tag name, and you
try to merge them all at once with a multi-parent commit.  

Sure, tags refer to trees, not commits, so you don't necessarily have to
do this tag resolution at commit time (indeed, since commits don't refer
to tags, you *can't* do that resolution atomically on commit.)

But if you do pull tags into the local .git/refs/tags on merge, then you
will want to either resolve the conflict or supercede those tags, and at
that point you've got multiple equally valid tags in the histories that
are being superceded.  Doing so is a porcelain issue, but the core will
still need to understand tags with multiple supercedes: lines.

--Stephen

Re: Suggestion: superceded tags

[H. Peter Anvin]

Stephen C. Tweedie wrote:
> Hi,
> 
> On Fri, 2005-05-27 at 06:29, H. Peter Anvin wrote:
> 
> 
>>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.
> 
> Strictly speaking, don't you need to allow multiple "supercedes" lines
> to cover all the cases?  The pathological case is when you've got
> multiple trees all with different variants of the same tag name, and you
> try to merge them all at once with a multi-parent commit.  
> 
> Sure, tags refer to trees, not commits, so you don't necessarily have to
> do this tag resolution at commit time (indeed, since commits don't refer
> to tags, you *can't* do that resolution atomically on commit.)
> 
> But if you do pull tags into the local .git/refs/tags on merge, then you
> will want to either resolve the conflict or supercede those tags, and at
> that point you've got multiple equally valid tags in the histories that
> are being superceded.  Doing so is a porcelain issue, but the core will
> still need to understand tags with multiple supercedes: lines.
> 

Indeed, multiple supercedes lines are useful to conver the resolution of 
a tag conflict.

	-hpa