# odd name-rev behavior? 5 messages from 2011-11-15 to 2011-11-16. Participants: Tim Walberg, Junio C Hamano. Thread: https://gitlist.dev/t/28942 ## Tim Walberg, 2011-11-15 21:15 Subject: odd name-rev behavior? Message-ID: <20111115211514.GE27706@comcast.net> URL: https://gitlist.dev/e/20111115211514.GE27706%40comcast.net ``` Never noticed this before - is this expected? It doesn't seem to match documentation, in any case... Basically, 'git name-rev --all' lists a lot of lines that are marked as "undefined", and most, if not all, of the objects represented are trees, not commits... I wouldn't have expected name-rev to follow the link from a commit to a tree and try to process that result... > git --version git version 1.7.7.3 > git name-rev --all | tail -10 ed858730bc0e40d5317543ca4a199f1902b1c545 master~35 ea6d0d16af77b357caab59bda3eff8efe78370c1 undefined ea01449260d4ed49cc30ffff8fa840273e182195 undefined f0a186fa05e9d4dd2de85ab537ac019a74b84736 undefined f223486e4178e0b2d6645fa3d0478602a6aec548 undefined f6f969d943f981057d9243d5fc2d8a79864cb542 master~19 f73dc68c32681939d2ce92378128889c7b6a8902 master~90 f739f050f0a20692e947604d0d5a464cdd5393aa master~109 faa7bf622b69c93f1f21eec0de3bd0ab6957b888 master~94 ff41d4390d3fabf1ba886749a51a20722b159fdd undefined > git cat-file -t ff41d4 tree > -- +----------------------+ | Tim Walberg | | 830 Carriage Dr. | | Algonquin, IL 60102 | | twalberg@comcast.net | +----------------------+ ``` ## Junio C Hamano, 2011-11-15 23:20 Subject: Re: odd name-rev behavior? Message-ID: <7vpqgtt1kb.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vpqgtt1kb.fsf%40alter.siamese.dyndns.org In-Reply-To: <20111115211514.GE27706@comcast.net> ``` Tim Walberg writes: > Never noticed this before - is this expected? It doesn't seem to > match documentation, in any case... > > Basically, 'git name-rev --all' lists a lot of lines that are > marked as "undefined", and most, if not all, of the objects > represented are trees, not commits... I wouldn't have expected > name-rev to follow the link from a commit to a tree and try to > process that result... I wouldn't either, but this does not look like a recent breakage. v1.6.0 seems to show the same broken behaviour. ``` ## Junio C Hamano, 2011-11-15 23:23 Subject: Re: odd name-rev behavior? Message-ID: <7vlirht1fw.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlirht1fw.fsf%40alter.siamese.dyndns.org In-Reply-To: <7vpqgtt1kb.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Tim Walberg writes: > >> Never noticed this before - is this expected? It doesn't seem to >> match documentation, in any case... >> >> Basically, 'git name-rev --all' lists a lot of lines that are >> marked as "undefined", and most, if not all, of the objects >> represented are trees, not commits... I wouldn't have expected >> name-rev to follow the link from a commit to a tree and try to >> process that result... > > I wouldn't either, but this does not look like a recent breakage. v1.6.0 > seems to show the same broken behaviour. And this one-liner should be sufficient (untested). builtin/name-rev.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/builtin/name-rev.c b/builtin/name-rev.c index 7864056..1b37458 100644 --- a/builtin/name-rev.c +++ b/builtin/name-rev.c @@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix) max = get_max_object_index(); for (i = 0; i < max; i++) { struct object *obj = get_indexed_object(i); - if (!obj) + if (!obj || obj->type != OBJ_COMMIT) continue; show_name(obj, NULL, always, allow_undefined, data.name_only); ``` ## Tim Walberg, 2011-11-16 01:48 Subject: Re: odd name-rev behavior? Message-ID: <20111116014842.GF27706@comcast.net> URL: https://gitlist.dev/e/20111116014842.GF27706%40comcast.net In-Reply-To: <7vlirht1fw.fsf@alter.siamese.dyndns.org> ``` That does indeed seem to work on first try. Not sure it was a particularly critical issue - just unexpected. For what I was using it for it was simple to work around. But thanks for the quick fix! tw On 11/15/2011 15:23 -0800, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> > Tim Walberg writes: >> > >> >> Never noticed this before - is this expected? It doesn't seem to >> >> match documentation, in any case... >> >> >> >> Basically, 'git name-rev --all' lists a lot of lines that are >> >> marked as "undefined", and most, if not all, of the objects >> >> represented are trees, not commits... I wouldn't have expected >> >> name-rev to follow the link from a commit to a tree and try to >> >> process that result... >> > >> > I wouldn't either, but this does not look like a recent breakage. v1.6.0 >> > seems to show the same broken behaviour. >> >> And this one-liner should be sufficient (untested). >> >> builtin/name-rev.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/builtin/name-rev.c b/builtin/name-rev.c >> index 7864056..1b37458 100644 >> --- a/builtin/name-rev.c >> +++ b/builtin/name-rev.c >> @@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix) >> max = get_max_object_index(); >> for (i = 0; i < max; i++) { >> struct object *obj = get_indexed_object(i); >> - if (!obj) >> + if (!obj || obj->type != OBJ_COMMIT) >> continue; >> show_name(obj, NULL, >> always, allow_undefined, data.name_only); End of included message -- +----------------------+ | Tim Walberg | | 830 Carriage Dr. | | Algonquin, IL 60102 | | twalberg@comcast.net | +----------------------+ ``` ## Junio C Hamano, 2011-11-16 05:41 Subject: Re: odd name-rev behavior? Message-ID: <7vr518sjyq.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vr518sjyq.fsf%40alter.siamese.dyndns.org In-Reply-To: <20111116014842.GF27706@comcast.net> ``` Tim Walberg writes: > That does indeed seem to work on first try. Not sure it was > a particularly critical issue - just unexpected. I didn't think it is particularly critical, either, and that is why I said it has been like this for eons at least since v1.6.0. And it turns out that this was pretty much from day one of name-rev at bd321bc (Add git-name-rev, 2005-10-26). ```