{"thread":{"id":"1424","subject":"Tree tags again..","startedAt":"2005-08-05T00:03:17Z","lastAt":"2005-08-05T09:16:56Z","messageCount":3,"participants":["Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6829","messageId":"Pine.LNX.4.58.0508041702180.3258@g5.osdl.org","threadId":"1424","inReplyTo":null,"subject":"Tree tags again..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-05T00:03:17Z","receivedAt":"2005-08-05T00:03:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nJunio, maybe there should be some test-case for this:\n\n\terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n\terror: remote ref 'refs/tags/v2.6.11' is not a strict subset of local ref 'refs/tags/v2.6.11'.\n\terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n\terror: remote ref 'refs/tags/v2.6.11-tree' is not a strict subset of local ref 'refs/tags/v2.6.11-tree'.\n\nHmm?\n\n\t\tLinus\n"},{"id":"6833","messageId":"7vu0i5qlsc.fsf@assigned-by-dhcp.cox.net","threadId":"1424","inReplyTo":"Pine.LNX.4.58.0508041702180.3258@g5.osdl.org","subject":"Re: Tree tags again..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-05T00:17:55Z","receivedAt":"2005-08-05T00:17:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Junio, maybe there should be some test-case for this:\n>\n> \terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n> \terror: remote ref 'refs/tags/v2.6.11' is not a strict subset of local ref 'refs/tags/v2.6.11'.\n\nI assume this is syncing two linux-2.6 repo which both have the\nsame refs/tags/v2.6.11 (tree tag).\n\nSorry, in send_pack(), up-to-date check should be made first\nbefore ref_newer() check.  My mistake.\n\nA more interesting question is what to do if they are indeed\ndifferent trees.  More realistically, you may decide to\nretroactively create a commit that wraps the same v2.6.11 tree,\nperhaps grafting it in front of the current 2.6.12-rcX based\nhistory, and replace 'refs/tags/v2.6.11' with a tag to that\ncommit.  What should happen?\n\nI do not have a good answer to that.  From the end-user point of\nview, we _could_ treat tags differently from heads in that we\nalways omit the ref_newer() check, but from the machinery point\nof view, I think the plumbing should just ask the user to use\nthe --force when such a tag is involved.\n\n------------\ndiff --git a/send-pack.c b/send-pack.c\n--- a/send-pack.c\n+++ b/send-pack.c\n@@ -173,6 +173,10 @@ static int send_pack(int in, int out, in\n \t\tchar old_hex[60], *new_hex;\n \t\tif (!ref->peer_ref)\n \t\t\tcontinue;\n+\t\tif (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {\n+\t\t\tfprintf(stderr, \"'%s': up-to-date\\n\", ref->name);\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!is_zero_sha1(ref->old_sha1)) {\n \t\t\tif (!has_sha1_file(ref->old_sha1)) {\n \t\t\t\terror(\"remote '%s' object %s does not \"\n@@ -188,10 +192,6 @@ static int send_pack(int in, int out, in\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t}\n-\t\tif (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {\n-\t\t\tfprintf(stderr, \"'%s': up-to-date\\n\", ref->name);\n-\t\t\tcontinue;\n-\t\t}\n \t\tmemcpy(ref->new_sha1, ref->peer_ref->new_sha1, 20);\n \t\tif (is_zero_sha1(ref->new_sha1)) {\n \t\t\terror(\"cannot happen anymore\");\n"},{"id":"6846","messageId":"7virykn3p3.fsf@assigned-by-dhcp.cox.net","threadId":"1424","inReplyTo":"Pine.LNX.4.58.0508041702180.3258@g5.osdl.org","subject":"Re: Tree tags again..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-05T09:16:56Z","receivedAt":"2005-08-05T09:16:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sorry about the breakage.  I pushed out a fix.\n\nSince you always give me hard time with this \"tree-tag\", I\ndecided to trump it with an even weirder tag myself.  We will\nsee what else would break shortly ;-).\n"}]}