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 better. > 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. -Daniel *This .sig left intentionally blank* - 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.htmlReceived on Tue Apr 19 15:31:26 2005
This archive was generated by hypermail 2.1.8 : 2005-04-19 15:31:26 EST