Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)

[Vicent Marti <vicent@github.com>]

Yo!

On Sun, Mar 20, 2011 at 12:55 PM, Pavel Raiskup <xraisk00@gmail.com> 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