Hi, On Thu, 15 Mar 2007, Junio C Hamano wrote: > "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. Isn't this an awfully long shot? I'd be happy if the libification project resulted - in a (static!) libgit.a which can be linked to qgit or similar (being reentrant, or at least optionally so, and not die()ing all the time), and - which does not fix the API yet (at least for the most parts). We _can_ -- once we agree on a stable API -- expose _some_ functions in a libgit.so, but that does not have to be the goal for the first step! Ciao, Dscho - 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