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@xxxxxxxxxx> 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. -- 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
