Re: odd name-rev behavior?

[Tim Walberg <twalberg@comcast.net>]

[-- 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 --]