Re: [1/4] Report info from trees

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> This patch adds actual information to struct tree, making it possible to
DB> tell what sorts of things the referenced objects are. This is needed for
DB> http-pull, and Junio wanted something of the sort.

Thanks for keeping me in the loop, but...

DB> --- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.h  (mode:100644 sha1:14ebbacded09d5e058c7f94652dcb9e12bc31cae)
DB> +++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.h  (mode:100644 sha1:985500e2a9130fe8c33134ca121838af9320c465)
DB> @@ -5,9 +5,20 @@
 
DB>  extern const char *tree_type;
 
DB> +struct tree_entry_list {
DB> +	struct tree_entry_list *next;
DB> +	unsigned directory : 1;
DB> +	unsigned executable : 1;
DB> +	union {
DB> +		struct tree *tree;
DB> +		struct blob *blob;
DB> +	} item;
DB> +};
DB> +
DB>  struct tree {
DB>  	struct object object;
DB>  	unsigned has_full_path : 1;
DB> +	struct tree_entry_list *entries;
DB>  };
 
... what about names?  When somebody other than connectivity
checker walks a tree, it would be more likely than not that 
it wants to know what each entry is called, wound't it?

I can get the type of the object, either tree or blob, from
tree->object.type, so I do not think the single-bit are needed.

Instead, how about something simpler like this?

    struct tree {
        struct object object; /* the tree node itself as an object */
        unsigned child_nr;
        unsigned child_alloc;
        struct {
            struct object *object;
            char *name;
        } **child;
    };

The tree->child[n].object would point at the same object as one
of the object_list elements in tree->object.refs chain (i.e. you
do not need to read the same object twice).  Before the tree is
parsed, tree->child would be NULL.  You do not need child_alloc
if the intended use of this API is only parsing existing object
tree.  Otherwise keep that and realloc tree->child as needed.



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html