On Mon, 18 Apr 2005, Junio C Hamano wrote:

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

Yes; just add the name to the tree_entry_list.

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

You still need the mode bit (executable or not); also, the current code
can't create an object without being told in advance what it is, so you
need to use the directory bit.

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

I think the linked list is easier to deal with, and matches the other code

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

The object code handles causing lookup_* to return the same object every
time, so this isn't an issue. Note that each struct object has to be
embedded in a struct <type> of the appropriate type, which means that we
can only create a struct object by either knowing what type it is supposed
to be or actually reading the file to find out what it actually is.

*This .sig left intentionally blank*

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

Reply via email to