"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <junkio@xxxxxxx> wrote: >> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: >> > On the other hand, many of the variables declared in environment.c >> > are repository specific configuration variables. These probably >> > should be abstracted into some sort of wrapper, so that multiple >> > repositories can be accessed from within the same process. Why? >> > a future mod_perl running gitweb.cgi accessing repositories through >> > libgit.a and Perl bindings of course! >> >> I think if you are abstracting them out, into "struct repo_state", >> the index and object store related variables such as packed_git >> should go there as well, so your recommendation feels very >> inconsistent to me. > > I missed packed_git, but you are right, that should definately go > with a struct repo_state. And maybe you are right that the index > should go with it... but I'm not sure the index should be tied to the > repository at all. Its strictly convention that the index goes with > the repository; GIT_INDEX_FILE lets you say otherwise at the command > line level, why can't we do otherwise from a library level too? Even within a plumbing, being able to shuffle multiple indices at once would be very useful. For example, if I were to rewrite unpack-trees, I would most likely read from the current index and trees and populate a new index from emptiness by appending to it, thereby avoiding the binary-search and insert costs. I've thought about the layering when Smurf first brought up the libification (which was a loooong time ago), and concluded three layered approach would be most useful. The bottom layer is object store across repositories. If we ignore SHA-1 collisions as an issue (and we _will_ ignore it for forseeable future), unless you are doing "read from one repository and write that to another repository", it is more handy to be able to name an object and get its data without knowing which repository's object store it comes from, and it would make "git log master~A..master~B" across repositories (i.e. 'master' of repository A and 'master' of repository B) possible. An example interface would be like: (current) void *read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size); (libified) void *git_read_sha1_file(struct gitlib *, const unsigned char *sha1, enum object_type *type, unsigned long *size); where "struct gitlib" has a list of "struct object_store", and we will have: int git_add_object_store(struct gitlib *, const char *path); to add one directory as object store the toplevel gitlib structure knows about. In a sense, "struct gitlib" and object store is so global that we might not even need to have it as a parameter (iow, it and "struct object **obj_hash" from object.c can stay global). The middle layer is repositories, primarily their refs and reflogs. An example interface would be like: (current) int get_sha1(const char *name, unsigned char *sha1); (libified) int git_get_sha1(struct git_repo *, const char *name, unsigned char *sha1); where "struct git_repo" is one repository (and it would have a pointer to "struct gitlib *" so that we can follow objects to follow parents and stuff). And the top layer would have indices, and working trees as per-invocation parameter. (current) int cache_name_pos(const char *name, int namelen); int unpack_trees(struct object_list *trees, struct unpack_trees_options *o); (libified) int git_cache_name_pos(struct git_cache *, const char *name, int namelen); int git_unpack_trees(struct object_list *trees, struct git_unpack_trees_options *o); where "struct git_cache" has "index" thingies, such as active_cache, active_nr, active_alloc, and active_cache_tree. And we would have pointer to "struct git_cache *" in unpack_trees_options structure. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html