threads / discuss / 28942

odd name-rev behavior?

Subject: odd name-rev behavior?

## tl;dr

5 messages between Nov 15, 2011 and Nov 16, 2011.

replies: 4people: 2as markdown or json

Tim Walberg· Nov 15, 2011, 21:15 UTC · lore

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· Nov 15, 2011, 23:20 UTC · re: Tim Walberg · lore

Re: odd name-rev behavior?

Tim Walberg <twalberg@comcast.net> writes:

Show 8 quoted lines

> 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· Nov 15, 2011, 23:23 UTC · re: Junio C Hamano · lore

Re: odd name-rev behavior?

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

> Tim Walberg <twalberg@comcast.net> 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· Nov 16, 2011, 01:48 UTC · re: Junio C Hamano · lore

Re: odd name-rev behavior?

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:

Show 34 quoted lines

>>	Junio C Hamano <gitster@pobox.com> writes:
>>	
>>	> Tim Walberg <twalberg@comcast.net> 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· Nov 16, 2011, 05:41 UTC · re: Tim Walberg · lore

Re: odd name-rev behavior?

Tim Walberg <twalberg@comcast.net> 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).