Re: Libification project (SoC)

[Junio C Hamano <junkio@cox.net>]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> 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.