odd name-rev behavior?

odd name-rev behavior?

[Tim Walberg]

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 |
+----------------------+

Re: odd name-rev behavior?

[Junio C Hamano]

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.

Re: odd name-rev behavior?

[Junio C Hamano]

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);

Re: odd name-rev behavior?

[Tim Walberg]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

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 <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 |
+----------------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: odd name-rev behavior?

[Junio C Hamano]

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).