{"thread":{"id":"35461","subject":"git log --no-walk --tags produces strange result for certain user","startedAt":"2013-12-03T10:08:25Z","lastAt":"2014-01-17T08:28:02Z","messageCount":11,"participants":["Kirill Likhodedov","brian m. carlson","Junio C Hamano","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231419","messageId":"5EE449B7-AB75-4EFF-85F9-292727FA1C53@jetbrains.com","threadId":"35461","inReplyTo":null,"subject":"git log --no-walk --tags produces strange result for certain user","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2013-12-03T10:08:25Z","receivedAt":"2013-12-03T10:08:25Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"Hey,\n\nI use the following commands to receive the list of tags together with hashes the point to:\n  \n    git log --tags --no-walk --format=%H%d%x01 --decorate=full\n\nGenerally it works fine, however a user reported that for his repository this command returns the list containing several hashes without tag references. Something like this:\n\n    05c9a3a6247698ff740ca3a79828456347afdcef (HEAD, tag: refs/tags/2.33, refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master)\u0001\n    a7fda708d76d7f83d5a160b6b137b98b7677f771 (tag: refs/tags/2.44)\n    f119c2e7c69bb5ed1da5bae29c8754550ab96bde\u0001\n    07385a6ebe5a2e01e6ba9c8d0cb7b15c9a13f65d (tag: refs/tags/1.69)\u0001\n\nHere third hash doesn't have a reference. There are 3 such hashes in his repository.\n\nHow can this happen? Is it a bug or some special scenario?\n\n* I've already asked the user to execute `git tag --points-at` on these \"suspiciously tagged\" hashes: nothing was returned.\n* `git show --decorate=full` executed on these hashes return commit details, and no references on them.\n* From the log user sees that these hashes indicate some \"normal\" commits, nothing special at first glance.\n\nGit version that he uses is 1.8.4.0.\n\nThanks!\n\n-- Kirill."},{"id":"231707","messageId":"01D3F259-94E1-4084-9210-34E2DB7B7545@jetbrains.com","threadId":"35461","inReplyTo":"5EE449B7-AB75-4EFF-85F9-292727FA1C53@jetbrains.com","subject":"Re: git log --no-walk --tags produces strange result for certain user","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2013-12-07T15:04:13Z","receivedAt":"2013-12-07T15:04:13Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"\n\nSorry for the duplication, but does anyone have an idea about this issue?\n\nI'm worried because I've already received reports from 3 users, and I'm not sure if just skipping these \"pseudo-tags\" is a correct decision.\n\nThanks for any help!\n\n-- Kirill.\n\nOn Dec 3, 2013, at 14:08 , Kirill Likhodedov <Kirill.Likhodedov@jetbrains.com> wrote:\n\n> Hey,\n> \n> I use the following commands to receive the list of tags together with hashes the point to:\n> \n>    git log --tags --no-walk --format=%H%d%x01 --decorate=full\n> \n> Generally it works fine, however a user reported that for his repository this command returns the list containing several hashes without tag references. Something like this:\n> \n>    05c9a3a6247698ff740ca3a79828456347afdcef (HEAD, tag: refs/tags/2.33, refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master)\u0001\n>    a7fda708d76d7f83d5a160b6b137b98b7677f771 (tag: refs/tags/2.44)\n>    f119c2e7c69bb5ed1da5bae29c8754550ab96bde\u0001\n>    07385a6ebe5a2e01e6ba9c8d0cb7b15c9a13f65d (tag: refs/tags/1.69)\u0001\n> \n> Here third hash doesn't have a reference. There are 3 such hashes in his repository.\n> \n> How can this happen? Is it a bug or some special scenario?\n> \n> * I've already asked the user to execute `git tag --points-at` on these \"suspiciously tagged\" hashes: nothing was returned.\n> * `git show --decorate=full` executed on these hashes return commit details, and no references on them.\n> * From the log user sees that these hashes indicate some \"normal\" commits, nothing special at first glance.\n> \n> Git version that he uses is 1.8.4.0.\n> \n> Thanks!\n> \n> -- Kirill.\n"},{"id":"232049","messageId":"AEF2BC21-6EE1-479F-BC63-7A5B95406A7F@jetbrains.com","threadId":"35461","inReplyTo":"52AEB181.9020006@alum.mit.edu","subject":"Re: git log --no-walk --tags produces strange result for certain user","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2013-12-16T11:52:35Z","receivedAt":"2013-12-16T11:52:35Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"\nHi everybody,\n\nI received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray \n\nTo reproduce:\n\n# git clone https://github.com/spray/spray \n# cd spray\n# git log --no-walk --tags --pretty=\"%H %d\" --decorate=full | tail -3\n3273edafcd9f9701d62e061c5257c0a09e2e1fb7  (tag: refs/tags/v0.8.0-RC1)\nff3a2946bc54da76ddb47e82c81419cc7ae3db6b  (tag: refs/tags/v0.7.0)\n8b4043428b90b7f45b7241b3c2c032cf785479ce \n\nSo here the last hash doesn't have a decoration.\n\nThanks for any help.\nKirill. \n"},{"id":"232088","messageId":"20131217004044.GB259467@vauxhall.crustytoothpaste.net","threadId":"35461","inReplyTo":"AEF2BC21-6EE1-479F-BC63-7A5B95406A7F@jetbrains.com","subject":"Re: git log --no-walk --tags produces strange result for certain user","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-12-17T00:40:44Z","receivedAt":"2013-12-17T00:40:44Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Dec 16, 2013 at 03:52:35PM +0400, Kirill Likhodedov wrote:\n> \n> Hi everybody,\n> \n> I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray \n> \n> To reproduce:\n> \n> # git clone https://github.com/spray/spray \n> # cd spray\n> # git log --no-walk --tags --pretty=\"%H %d\" --decorate=full | tail -3\n> 3273edafcd9f9701d62e061c5257c0a09e2e1fb7  (tag: refs/tags/v0.8.0-RC1)\n> ff3a2946bc54da76ddb47e82c81419cc7ae3db6b  (tag: refs/tags/v0.7.0)\n> 8b4043428b90b7f45b7241b3c2c032cf785479ce \n> \n> So here the last hash doesn't have a decoration.\n\nThis looks like a bug:\n\nvauxhall ok % git describe 8b4043428b90b7f45b7241b3c2c032cf785479ce\nv0.5.0\n\nI'm looking at it.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"232090","messageId":"1387254501-319329-1-git-send-email-sandals@crustytoothpaste.net","threadId":"35461","inReplyTo":"20131217004044.GB259467@vauxhall.crustytoothpaste.net","subject":"[PATCH] log: properly handle decorations with chained tags","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-12-17T04:28:21Z","receivedAt":"2013-12-17T04:28:21Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"git log did not correctly handle decorations when a tag object referenced\nanother tag object that was no longer a ref, such as when the second tag was\ndeleted.  The commit would not be decorated correctly because parse_object had\nnot been called on the second tag and therefore its tagged field had not been\nfilled in, resulting in none of the tags being associated with the relevant\ncommit.\n\nCall parse_object to fill in this field if it is absent so that the chain of\ntags can be dereferenced and the commit can be properly decorated.  Include\ntests as well to prevent future regressions.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n log-tree.c                    | 13 ++++++++++---\n t/t4205-log-pretty-formats.sh | 15 +++++++++++++++\n 2 files changed, 25 insertions(+), 3 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 642faff..a6b60b7 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -131,9 +131,16 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n \t\trefname = prettify_refname(refname);\n \tadd_name_decoration(type, refname, obj);\n \twhile (obj->type == OBJ_TAG) {\n-\t\tobj = ((struct tag *)obj)->tagged;\n-\t\tif (!obj)\n-\t\t\tbreak;\n+\t\tstruct object *tagged = ((struct tag *)obj)->tagged;\n+\t\tif (!tagged) {\n+\t\t\tobj = parse_object(obj->sha1);\n+\t\t\tif (!obj)\n+\t\t\t\tbreak;\n+\t\t\ttagged = ((struct tag *)obj)->tagged;\n+\t\t\tif (!tagged)\n+\t\t\t\tbreak;\n+\t\t}\n+\t\tobj = tagged;\n \t\tadd_name_decoration(DECORATION_REF_TAG, refname, obj);\n \t}\n \treturn 0;\ndiff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh\nindex fb00041..2a6278b 100755\n--- a/t/t4205-log-pretty-formats.sh\n+++ b/t/t4205-log-pretty-formats.sh\n@@ -310,4 +310,19 @@ EOF\n \ttest_cmp expected actual\n '\n \n+test_expect_success 'log decoration properly follows tag chain' '\n+\tgit tag -a tag1 -m tag1 &&\n+\tgit tag -a tag2 -m tag2 tag1 &&\n+\tgit tag -d tag1 &&\n+\tgit commit --amend -m shorter &&\n+\tgit log --no-walk --tags --pretty=\"%H %d\" --decorate=full >actual &&\n+\tcat <<EOF >expected &&\n+6a908c10688b2503073c39c9ba26322c73902bb5  (tag: refs/tags/tag2)\n+9f716384d92283fb915a4eee5073f030638e05f9  (tag: refs/tags/message-one)\n+b87e4cccdb77336ea79d89224737be7ea8e95367  (tag: refs/tags/message-two)\n+EOF\n+\tsort actual >actual1 &&\n+\ttest_cmp expected actual1\n+'\n+\n test_done\n-- \n1.8.5.1\n"},{"id":"232132","messageId":"xmqq38lrknbd.fsf@gitster.dls.corp.google.com","threadId":"35461","inReplyTo":"1387254501-319329-1-git-send-email-sandals@crustytoothpaste.net","subject":"Re: [PATCH] log: properly handle decorations with chained tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-18T00:36:06Z","receivedAt":"2013-12-18T00:36:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n>  \t\trefname = prettify_refname(refname);\n>  \tadd_name_decoration(type, refname, obj);\n>  \twhile (obj->type == OBJ_TAG) {\n> -\t\tobj = ((struct tag *)obj)->tagged;\n> -\t\tif (!obj)\n> -\t\t\tbreak;\n> +\t\tstruct object *tagged = ((struct tag *)obj)->tagged;\n> +\t\tif (!tagged) {\n> +\t\t\tobj = parse_object(obj->sha1);\n> +\t\t\tif (!obj)\n> +\t\t\t\tbreak;\n> +\t\t\ttagged = ((struct tag *)obj)->tagged;\n> +\t\t\tif (!tagged)\n> +\t\t\t\tbreak;\n> +\t\t}\n> +\t\tobj = tagged;\n>  \t\tadd_name_decoration(DECORATION_REF_TAG, refname, obj);\n>  \t}\n\nOK, the above is not wrong per-se but it took me three reads to\nconvince myself that I understood what was going on.\n\nBefore entering this loop, obj has already been parsed, it is known\nto be an annotated tag object, and its obj->tagged field is valid,\nbut the object pointed at by the tag may still not be parsed yet.\nThe object given to add_name_decoration() before we enter the loop\nhas been parsed, but the one given at the end of this loop is not.\n\nI think all we need to do, in addition to what the existing code\ndoes, is to make sure that we _parse_ the object that the tag points\nat, to avoid this problem.  Something like this, perhaps, instead?\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 8534d91..1982631 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -132,10 +132,12 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n \tadd_name_decoration(type, refname, obj);\n \twhile (obj->type == OBJ_TAG) {\n \t\tobj = ((struct tag *)obj)->tagged;\n \t\tif (!obj)\n \t\t\tbreak;\n+\t\tif (!obj->parsed)\n+\t\t\tparse_object(obj->sha1);\n \t\tadd_name_decoration(DECORATION_REF_TAG, refname, obj);\n \t}\n \treturn 0;\n }\n \nIt seems to me that the above is not just sufficient, but also shows\nwhat the breakage was really about a lot more clearly, at least to\nme.\n\nHmm?\n\n> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh\n> index fb00041..2a6278b 100755\n> --- a/t/t4205-log-pretty-formats.sh\n> +++ b/t/t4205-log-pretty-formats.sh\n> @@ -310,4 +310,19 @@ EOF\n>  \ttest_cmp expected actual\n>  '\n>  \n> +test_expect_success 'log decoration properly follows tag chain' '\n> +\tgit tag -a tag1 -m tag1 &&\n> +\tgit tag -a tag2 -m tag2 tag1 &&\n> +\tgit tag -d tag1 &&\n> +\tgit commit --amend -m shorter &&\n> +\tgit log --no-walk --tags --pretty=\"%H %d\" --decorate=full >actual &&\n> +\tcat <<EOF >expected &&\n> +6a908c10688b2503073c39c9ba26322c73902bb5  (tag: refs/tags/tag2)\n> +9f716384d92283fb915a4eee5073f030638e05f9  (tag: refs/tags/message-one)\n> +b87e4cccdb77336ea79d89224737be7ea8e95367  (tag: refs/tags/message-two)\n> +EOF\n> +\tsort actual >actual1 &&\n> +\ttest_cmp expected actual1\n> +'\n> +\n>  test_done\n"},{"id":"232227","messageId":"20131219031809.GG259467@vauxhall.crustytoothpaste.net","threadId":"35461","inReplyTo":"xmqq38lrknbd.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] log: properly handle decorations with chained tags","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-12-19T03:18:09Z","receivedAt":"2013-12-19T03:18:09Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Dec 17, 2013 at 04:36:06PM -0800, Junio C Hamano wrote:\n> I think all we need to do, in addition to what the existing code\n> does, is to make sure that we _parse_ the object that the tag points\n> at, to avoid this problem.  Something like this, perhaps, instead?\n\nYeah, that's the clean fix I was looking for, but couldn't quite come up\nwith.  I'm going to re-roll with your fix instead of mine and my tests.\nAny objections to adding your sign-off?\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"232244","messageId":"xmqqfvpofzp5.fsf@gitster.dls.corp.google.com","threadId":"35461","inReplyTo":"20131219031809.GG259467@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] log: properly handle decorations with chained tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-19T18:44:22Z","receivedAt":"2013-12-19T18:44:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> On Tue, Dec 17, 2013 at 04:36:06PM -0800, Junio C Hamano wrote:\n>> I think all we need to do, in addition to what the existing code\n>> does, is to make sure that we _parse_ the object that the tag points\n>> at, to avoid this problem.  Something like this, perhaps, instead?\n>\n> Yeah, that's the clean fix I was looking for, but couldn't quite come up\n> with.  I'm going to re-roll with your fix instead of mine and my tests.\n> Any objections to adding your sign-off?\n\nI was actually planning to just squash 35a34ce281 as a fixup! to\nyour 5e65a201 and call it a day.  I think your proposed log message\nin the latter clearly describes why the fix is correct.\n"},{"id":"232271","messageId":"20131219234442.GI259467@vauxhall.crustytoothpaste.net","threadId":"35461","inReplyTo":"xmqqfvpofzp5.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] log: properly handle decorations with chained tags","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-12-19T23:44:42Z","receivedAt":"2013-12-19T23:44:42Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Thu, Dec 19, 2013 at 10:44:22AM -0800, Junio C Hamano wrote:\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n> > Yeah, that's the clean fix I was looking for, but couldn't quite come up\n> > with.  I'm going to re-roll with your fix instead of mine and my tests.\n> > Any objections to adding your sign-off?\n> \n> I was actually planning to just squash 35a34ce281 as a fixup! to\n> your 5e65a201 and call it a day.  I think your proposed log message\n> in the latter clearly describes why the fix is correct.\n\nOkay, sounds good.  Thanks.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"233201","messageId":"52D7B4F8.1010209@alum.mit.edu","threadId":"35461","inReplyTo":"AEF2BC21-6EE1-479F-BC63-7A5B95406A7F@jetbrains.com","subject":"Re: git log --no-walk --tags produces strange result for certain user","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-01-16T10:31:20Z","receivedAt":"2014-01-16T10:31:20Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 12/16/2013 12:52 PM, Kirill Likhodedov wrote:\n> I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray \n> \n> To reproduce:\n> \n> # git clone https://github.com/spray/spray \n> # cd spray\n> # git log --no-walk --tags --pretty=\"%H %d\" --decorate=full | tail -3\n> 3273edafcd9f9701d62e061c5257c0a09e2e1fb7  (tag: refs/tags/v0.8.0-RC1)\n> ff3a2946bc54da76ddb47e82c81419cc7ae3db6b  (tag: refs/tags/v0.7.0)\n> 8b4043428b90b7f45b7241b3c2c032cf785479ce \n> \n> So here the last hash doesn't have a decoration.\n\nThe problem is that reference refs/tags/v0.5.0 points at a tag object\n8f6ca98087 which itself points at another tag object 2eddbcbff4 which\nfinally points at commit 8b4043428b.  Probably we should handle\nrecursive tag objects like this, but OTOH I can't think of a reason why\none would want to create them in the first place.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"233268","messageId":"52D8E992.3010304@alum.mit.edu","threadId":"35461","inReplyTo":"52D7B4F8.1010209@alum.mit.edu","subject":"Re: git log --no-walk --tags produces strange result for certain user","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-01-17T08:28:02Z","receivedAt":"2014-01-17T08:28:02Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/16/2014 11:31 AM, Michael Haggerty wrote:\n> On 12/16/2013 12:52 PM, Kirill Likhodedov wrote:\n>> I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray \n>>\n>> To reproduce:\n>>\n>> # git clone https://github.com/spray/spray \n>> # cd spray\n>> # git log --no-walk --tags --pretty=\"%H %d\" --decorate=full | tail -3\n>> 3273edafcd9f9701d62e061c5257c0a09e2e1fb7  (tag: refs/tags/v0.8.0-RC1)\n>> ff3a2946bc54da76ddb47e82c81419cc7ae3db6b  (tag: refs/tags/v0.7.0)\n>> 8b4043428b90b7f45b7241b3c2c032cf785479ce \n>>\n>> So here the last hash doesn't have a decoration.\n> \n> The problem is that reference refs/tags/v0.5.0 points at a tag object\n> 8f6ca98087 which itself points at another tag object 2eddbcbff4 which\n> finally points at commit 8b4043428b.  Probably we should handle\n> recursive tag objects like this, but OTOH I can't think of a reason why\n> one would want to create them in the first place.\n\nJunio just pointed out to me that this bug has been fixed already, by\nBrian Carlson, in 5e1361cc, which is already in master.  Sorry for the\nnoise.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}