Re: libgit2 - a true git library

["Shawn O. Pearce" <spearce@spearce.org>]

Yet more updates to the API:

http://www.spearce.org/projects/scm/libgit2/apidocs/html/modules.html

In particular I've started to define what revision machinary might
look like, based somewhat on JGit's (public) RevWalk API.  The guts
of how to make it work of course aren't yet defined.

My goal here is to have the git_revp_t be non-thread safe, but
also to contain the entire object pool, so git_revp_free() will
dispose of any and all git_commit_t's which were created from it.

This "fixes" the "we leak everything" behavior and allows
applications to have multiple pools on different threads if
it needs to.  Thus the core git_revp_t isn't thread-safe and
doesn't get weighed down by locking if the application wants
multiple threads.


Pierre Habouzit <madcoder@debian.org> wrote:
> 
> Well, I propose the following: we set-up on GNU-ld + gcc enabled systems
> all what is needed to use symbol visibility, which isn't that intrusive,
> and also rather easy given your GIT_EXPORT macro definition.

Yes, agreed.  Only I don't know how to do it myself.  I know its
possible, so if someone wants to contribute a patch for this ... :-)
 
> No, my worry was rather wrt git core itself, I really think we _must_
> make it link against libgit2 if we want libgit2 to stay current, but git
> core will _very likely_ need the private stuff, and it _will_ be a
> problem. I mean we cannot seriously so-name a library and show its guts
> at the same time, and I'm unsure how to fix that problem. _that_ was my
> actual question.

Hmmph.  I agree git-core needs to link to libgit2.

I disagree it needs private bits.  If we do the library right
git-core can use the public API.  And where it cannot its either
not something that is "right" for libgit2 (e.g. its parseopts and
we aren't committed yet to including option parsing) or its highly
experimental and we shouldn't put it into the library (and thus
also git-core) until its more frozen.

That said, I don't think its criminal to have git-core include and
link to a static libgit2, especially if git-core's usage of the
library is ahead of what the library itself is able to expose at
the present time.
 
> I'd say we should do both at the same time. Asking people if they would
> agree to relicense code can be done in parallel. We could extract a list
> of source files that we may need (my extraction included stuff that is
> very unlikely to be useful like test-*.c that aren't useful, and some
> that are already BSD I think), and see who it yields. It should be
> possible to do a matrix source-file x people and see on a per-file basis
> what they think.
> 
> If someone gives me the list of files we should consider (I'm not sure
> about a good list right now) I could do the matrix at some fixed sha1
> from git.git using git blame -C -M -M -w, and ask people see where it
> leads us ?

Off the top of my head some really important ones:

	diff-delta.c
	object.c
	patch-delta.c
	refs.c
	revision.c
	sha1_file.c
	sha1_name.c

They form a pretty large part of the guts of what most people want
from a git library.

Slightly less important, but still fairly core:

	builtin-fetch-pack.c
	builtin-send-pack.c
	connect.c
	remote.c
	transport.c

Is most of the client side of the git:// transport, something people want.

-- 
Shawn.