{"thread":{"id":"28942","subject":"odd name-rev behavior?","startedAt":"2011-11-15T21:15:14Z","lastAt":"2011-11-16T05:41:01Z","messageCount":5,"participants":["Tim Walberg","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179530","messageId":"20111115211514.GE27706@comcast.net","threadId":"28942","inReplyTo":null,"subject":"odd name-rev behavior?","fromName":"Tim Walberg","fromEmail":"twalberg@comcast.net","sentAt":"2011-11-15T21:15:14Z","receivedAt":"2011-11-15T21:15:14Z","isPatch":false,"sender":{"key":"twalberg@comcast.net","avatar":null},"body":"Never noticed this before - is this expected? It doesn't seem to\nmatch documentation, in any case...\n\nBasically, 'git name-rev --all' lists a lot of lines that are\nmarked as \"undefined\", and most, if not all, of the objects\nrepresented are trees, not commits... I wouldn't have expected\nname-rev to follow the link from a commit to a tree and try to\nprocess that result...\n\n> git --version\ngit version 1.7.7.3\n> git name-rev --all | tail -10\ned858730bc0e40d5317543ca4a199f1902b1c545 master~35\nea6d0d16af77b357caab59bda3eff8efe78370c1 undefined\nea01449260d4ed49cc30ffff8fa840273e182195 undefined\nf0a186fa05e9d4dd2de85ab537ac019a74b84736 undefined\nf223486e4178e0b2d6645fa3d0478602a6aec548 undefined\nf6f969d943f981057d9243d5fc2d8a79864cb542 master~19\nf73dc68c32681939d2ce92378128889c7b6a8902 master~90\nf739f050f0a20692e947604d0d5a464cdd5393aa master~109\nfaa7bf622b69c93f1f21eec0de3bd0ab6957b888 master~94\nff41d4390d3fabf1ba886749a51a20722b159fdd undefined\n> git cat-file -t ff41d4\ntree\n>\n\n\n-- \n+----------------------+\n| Tim Walberg |\n| 830 Carriage Dr. |\n| Algonquin, IL 60102 |\n| twalberg@comcast.net |\n+----------------------+\n"},{"id":"179540","messageId":"7vpqgtt1kb.fsf@alter.siamese.dyndns.org","threadId":"28942","inReplyTo":"20111115211514.GE27706@comcast.net","subject":"Re: odd name-rev behavior?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-15T23:20:52Z","receivedAt":"2011-11-15T23:20:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Walberg writes:\n\n> Never noticed this before - is this expected? It doesn't seem to\n> match documentation, in any case...\n>\n> Basically, 'git name-rev --all' lists a lot of lines that are\n> marked as \"undefined\", and most, if not all, of the objects\n> represented are trees, not commits... I wouldn't have expected\n> name-rev to follow the link from a commit to a tree and try to\n> process that result...\n\nI wouldn't either, but this does not look like a recent breakage. v1.6.0\nseems to show the same broken behaviour.\n"},{"id":"179541","messageId":"7vlirht1fw.fsf@alter.siamese.dyndns.org","threadId":"28942","inReplyTo":"7vpqgtt1kb.fsf@alter.siamese.dyndns.org","subject":"Re: odd name-rev behavior?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-15T23:23:31Z","receivedAt":"2011-11-15T23:23:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Tim Walberg writes:\n>\n>> Never noticed this before - is this expected? It doesn't seem to\n>> match documentation, in any case...\n>>\n>> Basically, 'git name-rev --all' lists a lot of lines that are\n>> marked as \"undefined\", and most, if not all, of the objects\n>> represented are trees, not commits... I wouldn't have expected\n>> name-rev to follow the link from a commit to a tree and try to\n>> process that result...\n>\n> I wouldn't either, but this does not look like a recent breakage. v1.6.0\n> seems to show the same broken behaviour.\n\nAnd this one-liner should be sufficient (untested).\n\n builtin/name-rev.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/name-rev.c b/builtin/name-rev.c\nindex 7864056..1b37458 100644\n--- a/builtin/name-rev.c\n+++ b/builtin/name-rev.c\n@@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)\n \t\tmax = get_max_object_index();\n \t\tfor (i = 0; i < max; i++) {\n \t\t\tstruct object *obj = get_indexed_object(i);\n-\t\t\tif (!obj)\n+\t\t\tif (!obj || obj->type != OBJ_COMMIT)\n \t\t\t\tcontinue;\n \t\t\tshow_name(obj, NULL,\n \t\t\t\t always, allow_undefined, data.name_only);\n"},{"id":"179546","messageId":"20111116014842.GF27706@comcast.net","threadId":"28942","inReplyTo":"7vlirht1fw.fsf@alter.siamese.dyndns.org","subject":"Re: odd name-rev behavior?","fromName":"Tim Walberg","fromEmail":"twalberg@comcast.net","sentAt":"2011-11-16T01:48:42Z","receivedAt":"2011-11-16T01:48:42Z","isPatch":false,"sender":{"key":"twalberg@comcast.net","avatar":null},"body":"That does indeed seem to work on first try. Not sure it was\na particularly critical issue - just unexpected. For what I\nwas using it for it was simple to work around. But thanks\nfor the quick fix!\n\n\t\t\ttw\n\n\nOn 11/15/2011 15:23 -0800, Junio C Hamano wrote:\n>>\tJunio C Hamano writes:\n>>\t\n>>\t> Tim Walberg writes:\n>>\t>\n>>\t>> Never noticed this before - is this expected? It doesn't seem to\n>>\t>> match documentation, in any case...\n>>\t>>\n>>\t>> Basically, 'git name-rev --all' lists a lot of lines that are\n>>\t>> marked as \"undefined\", and most, if not all, of the objects\n>>\t>> represented are trees, not commits... I wouldn't have expected\n>>\t>> name-rev to follow the link from a commit to a tree and try to\n>>\t>> process that result...\n>>\t>\n>>\t> I wouldn't either, but this does not look like a recent breakage. v1.6.0\n>>\t> seems to show the same broken behaviour.\n>>\t\n>>\tAnd this one-liner should be sufficient (untested).\n>>\t\n>>\t builtin/name-rev.c | 2 +-\n>>\t 1 files changed, 1 insertions(+), 1 deletions(-)\n>>\t\n>>\tdiff --git a/builtin/name-rev.c b/builtin/name-rev.c\n>>\tindex 7864056..1b37458 100644\n>>\t--- a/builtin/name-rev.c\n>>\t+++ b/builtin/name-rev.c\n>>\t@@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)\n>>\t \t\tmax = get_max_object_index();\n>>\t \t\tfor (i = 0; i < max; i++) {\n>>\t \t\t\tstruct object *obj = get_indexed_object(i);\n>>\t-\t\t\tif (!obj)\n>>\t+\t\t\tif (!obj || obj->type != OBJ_COMMIT)\n>>\t \t\t\t\tcontinue;\n>>\t \t\t\tshow_name(obj, NULL,\n>>\t \t\t\t\t always, allow_undefined, data.name_only);\nEnd of included message\n\n\n\n-- \n+----------------------+\n| Tim Walberg |\n| 830 Carriage Dr. |\n| Algonquin, IL 60102 |\n| twalberg@comcast.net |\n+----------------------+\n"},{"id":"179549","messageId":"7vr518sjyq.fsf@alter.siamese.dyndns.org","threadId":"28942","inReplyTo":"20111116014842.GF27706@comcast.net","subject":"Re: odd name-rev behavior?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-16T05:41:01Z","receivedAt":"2011-11-16T05:41:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Walberg writes:\n\n> That does indeed seem to work on first try. Not sure it was\n> a particularly critical issue - just unexpected.\n\nI didn't think it is particularly critical, either, and that is why I said\nit has been like this for eons at least since v1.6.0.\n\nAnd it turns out that this was pretty much from day one of name-rev at\nbd321bc (Add git-name-rev, 2005-10-26).\n"}]}