Yo! On Sun, Mar 20, 2011 at 12:55 PM, Pavel Raiskup <xraisk00@xxxxxxxxx> wrote: > libgit2: > I really like the concept of libraries for to be binding-able from dozens of > languages - this leads to expanding functionality among masses users > almost everywhere. In this part I like the idea of implementing new features > inside library (diff, config file parsing) but also maybe the task of > merging > libgit2 into git upstream. Basically I don't know much about that.. and > you wrote that this task is more difficult then others, so I probably need > to study git's and libgit's architecture very precisely beforehand .. but > could you tell me some details about that? Is it impossible to do it before > GSOC deadline and is it worth making a serious big efforts to this task > (from your point of view onto project objectives)? How big are requirements > for this task in term of GSOC? Merging libgit2 into upstream Git is a scary as fuck task. Somebody put it up on the Wiki ideas page, but that was not me -- I'm personally doubtful of anybody succeeding on doing that project during the SoC, so I have very little interest on mentoring the task. Here's what's going on: The Git code base is hairy and not that well documented, so you're gonna need to study that quite a bit. I like to think that the libgit2 code base is not hairy, and is pretty well documented (I'm an optimistic guy), but you're still going to need quite a bit of research to understand the whole architecture before you can actually merge anything into Git. You could try to port just some selected parts of the library to libgit2 (i.e. the parts which benchmark to be faster than their Git counterparts), but the interdependency chain of libgit2 internals is not going to be pretty, embedding into the Git core is not going to be easy (libgit2 is reentrant and mostly threadsafe, so there's quite the architecture mismatch there), and there's no guarantee that the final implementation is going to be faster once it's in there. Overall, you'd need balls of steel and a lot of spare time and interest to accomplish anything significant with this task, so my personal opinion as very old wise man is to forget about it. HOWEVER. If you want to do something libgit2-related for the SoC (which would be awesome), there's still two options: a) Help us make the library more awesome by implementing new features! This task is the opposite the previous one; it's like full of unicorns and rainbows. You can choose one (or more) features we are missing, and see how to implement them in libgit2 while making them reentrant, threadsafe AND faster. It's not easy, but it's fucking cool. And you get to do a lot of micro-optimization if you're into that. b) Write a minimal Git client using libgit2. Peff keeps bringing this up and I think it's a bangin' good idea. Write something small and 100% self contained in a C executable that runs everywhere with 0 dependencies -- don't aim for full feature completion, just the basic stuff to interoperate with a Git repository. Clone, checkout, branch, commit, push, pull, log. I would totally use that shit on my Windows boxes. And since it'll be externally compatible with the original Git client, we can reuse the Git unit tests to test libgit2. HA. Awesome! So, yeah. That's pretty much my libgit2-related advice for the SoC. Best of luck with your application process with whatever project you decide, Vicent -- 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