{"thread":{"id":"731","subject":"Suggestion: superceded tags","startedAt":"2005-05-27T05:29:53Z","lastAt":"2005-05-27T16:10:10Z","messageCount":3,"participants":["H. Peter Anvin","Stephen C. Tweedie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4035","messageId":"4296B051.10603@zytor.com","threadId":"731","inReplyTo":null,"subject":"Suggestion: superceded tags","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-27T05:29:53Z","receivedAt":"2005-05-27T05:29:53Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"It's a pretty fundamental concept in git that objects in the object \nrepository live forever.  This is key to distribution, and is a good thing.\n\nHowever, for tag objects, this is somewhat awkward.  It is occationally \nnecessary to move a tag (restarted release processes, being one reason); \npurists tend to frown on it but it's reality.\n\nIt would be nice to maintain that all tag information exists in the \nobject database and loss of the .git/refs directory will not harm that. \n  Thus, I'd like to suggest the following protocol:\n\nWhen a tag is moved, a new tag object is created.  This tag object will \nhave a \"supercedes\" header which references the old tag object.\n\nSay, for example, that tag \"klibc-1.0.14\", object \n4695b4d163b62f6a9860b9bbe06ff30edb6e02be, exists with the following \ncontents:\n\nobject fdb8a185ef261568f01140989745b8636212db71\ntype commit\ntag klibc-1.0.14\n\nNow \"klibc-1.0.14\" needs to be moved to new commit \n088c166af39b1ca2712667c44dccd3c7af99a8fb.\n\nThe new tag object should thus look like:\n\nobject 088c166af39b1ca2712667c44dccd3c7af99a8fb\ntype commit\nsupercedes 4695b4d163b62f6a9860b9bbe06ff30edb6e02be\ntag klibc-1.0.14\n\n(I put \"supercedes\" before \"tag\", because unfortunately the tag header \nterminates immediately after the \"tag\" line without having an \nintervening blank line.)\n\nThis will make it possible to move the tag, but still to recreate all \ntag information from the object database alone.\n\nNone of this can of course help the conflict if the same tag is created \nin different places by different people, and then they are trying to be \nmerged.  The above at least makes it possible to distinguish the case of \na tag conflict with the case of a moved tag, and in the case of the \nmoved tag, will stand out.\n\nOn the other hand, it makes it possible for more than one tag to exist \nwith the same name pointing to the same object:\n\nUser 1 creates tag X referring to object A\t-> T1\nUser 1 moves tag X to object B\t\t\t-> T2\nUser 2 creates tag X referring to object B\t-> T3\n\nThere is no conflict here, but T2 and T3 will be different objects (one \nwill supercede T1, and the other won't.)  An object-database-scanning \nprogram should observe that T2 and T3 are consistent, and T1 is \nsuperceded, therefore tag X is well-defined; it can arbitrarily use \neither instance T2 or T3.\n\n\t-hpa\n"},{"id":"4043","messageId":"1117193179.1957.28.camel@sisko.sctweedie.blueyonder.co.uk","threadId":"731","inReplyTo":"4296B051.10603@zytor.com","subject":"Re: Suggestion: superceded tags","fromName":"Stephen C. Tweedie","fromEmail":"sct@redhat.com","sentAt":"2005-05-27T11:26:20Z","receivedAt":"2005-05-27T11:26:20Z","isPatch":false,"sender":{"key":"sct@redhat.com","avatar":null},"body":"Hi,\n\nOn Fri, 2005-05-27 at 06:29, H. Peter Anvin wrote:\n\n> When a tag is moved, a new tag object is created.  This tag object will \n> have a \"supercedes\" header which references the old tag object.\n\nStrictly speaking, don't you need to allow multiple \"supercedes\" lines\nto cover all the cases?  The pathological case is when you've got\nmultiple trees all with different variants of the same tag name, and you\ntry to merge them all at once with a multi-parent commit.  \n\nSure, tags refer to trees, not commits, so you don't necessarily have to\ndo this tag resolution at commit time (indeed, since commits don't refer\nto tags, you *can't* do that resolution atomically on commit.)\n\nBut if you do pull tags into the local .git/refs/tags on merge, then you\nwill want to either resolve the conflict or supercede those tags, and at\nthat point you've got multiple equally valid tags in the histories that\nare being superceded.  Doing so is a porcelain issue, but the core will\nstill need to understand tags with multiple supercedes: lines.\n\n--Stephen\n\n\n"},{"id":"4050","messageId":"42974662.3040106@zytor.com","threadId":"731","inReplyTo":"1117193179.1957.28.camel@sisko.sctweedie.blueyonder.co.uk","subject":"Re: Suggestion: superceded tags","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-27T16:10:10Z","receivedAt":"2005-05-27T16:10:10Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Stephen C. Tweedie wrote:\n> Hi,\n> \n> On Fri, 2005-05-27 at 06:29, H. Peter Anvin wrote:\n> \n> \n>>When a tag is moved, a new tag object is created.  This tag object will \n>>have a \"supercedes\" header which references the old tag object.\n> \n> Strictly speaking, don't you need to allow multiple \"supercedes\" lines\n> to cover all the cases?  The pathological case is when you've got\n> multiple trees all with different variants of the same tag name, and you\n> try to merge them all at once with a multi-parent commit.  \n> \n> Sure, tags refer to trees, not commits, so you don't necessarily have to\n> do this tag resolution at commit time (indeed, since commits don't refer\n> to tags, you *can't* do that resolution atomically on commit.)\n> \n> But if you do pull tags into the local .git/refs/tags on merge, then you\n> will want to either resolve the conflict or supercede those tags, and at\n> that point you've got multiple equally valid tags in the histories that\n> are being superceded.  Doing so is a porcelain issue, but the core will\n> still need to understand tags with multiple supercedes: lines.\n> \n\nIndeed, multiple supercedes lines are useful to conver the resolution of \na tag conflict.\n\n\t-hpa\n"}]}