threads / discuss / 26702

Using libgit2 code in git.git as a Google Summer of Code project?

Subject: Using libgit2 code in git.git as a Google Summer of Code project?

## tl;dr

9 messages between Mar 10, 2011 and Mar 13, 2011.

replies: 8people: 5as markdown or json

Jonathan Nieder· Mar 10, 2011, 10:13 UTC · lore

Hey Vicent et al,

Vicent Marti wrote:

Show 8 quoted lines

>                                                           there have
> been proposals to merge parts of libgit2 into the original Git client;
> however, this is not one of our priorities (we are designing git.git
> to be embeddable in Git backends and GUI programs), and the library is
> not yet stable enough for that kind of job. We'll see what the future
> brings -- git.git would certainly benefit from some of our code, if
> anything because it's (slightly) faster and cleaner than the original
> implementation.

I've been thinking that it would be interested to start this work early on, partially so that libgit2 and git.git can get to know each other better so to speak (which could help libgit2 along nicely and help git get past some old limitations, I think). So I'm thinking of proposing stealing some of your code, with an eye toward eventually making git "just another libgit2 user", as a Google summer of code project idea.

Is that a sane idea? Is there any particular subset of the lib that would be an interesting place to start? Do you forsee any obstacles? Do you know anyone who might be interested in mentoring such a project?

Admittedly I'm not so familiar with libgit2 yet, so I'm willing to believe the answers might be no, no, yes, and no. ;-)

The Google Summer of Code application deadline is this Friday (March 11) at 23:00 UTC. If this does seem like a sane thing to do, it might be nice to put it on the ideas page at:

  https://git.wiki.kernel.org/index.php/SoC2011Ideas

Thanks for your work. Jonathan

Jonathan Nieder· Mar 10, 2011, 10:18 UTC · re: Jonathan Nieder · lore

(resending since my last mail was dropped; sorry for the noise) Hey Vicent et al,

Vicent Marti wrote:

Show 8 quoted lines

>                                                           there have
> been proposals to merge parts of libgit2 into the original Git client;
> however, this is not one of our priorities (we are designing git.git
> to be embeddable in Git backends and GUI programs), and the library is
> not yet stable enough for that kind of job. We'll see what the future
> brings -- git.git would certainly benefit from some of our code, if
> anything because it's (slightly) faster and cleaner than the original
> implementation.

Admittedly I'm not so familiar with libgit2 yet, so I'm willing to believe the answers might be no, no, yes, and no. ;-)

The Google Summer of Code application deadline is this Friday (March 11) at 23:00 UTC. If this does seem like a sane thing to do, it might be nice to put it on the ideas page at:

  https://git.wiki.kernel.org/index.php/SoC2011Ideas

Thanks for your work. Jonathan

Vicent Marti· Mar 10, 2011, 11:33 UTC · re: Jonathan Nieder · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Hey Jonathan,

I think that right now it would be a quite daunting task to start replacing parts of git.git with libgit2. The architecture changes required would be quite significant, because of the way that git.git and libgit2 are designed (Unix-only, non-reentrant/cross-platform, reentrant), and the biggest "feature" of libgit2, being able to compile all platforms (including native MSVC) would just now show because of the amount of original git.git code that would still be left on the code base. On top of that, the API for the library is not yet stable, so that integration may end up being kind-of-wasted work.

So, personally, I don't know anybody interested on mentoring *that* specific task, but I'm certainly interested on mentoring a "help complete libgit2" task: the earlier we stabilize the library, the earlier tasks like this one will be viable. Maybe on the next SoC? :)

Oh, and thanks for reminding me I need to put that task on the wiki before Friday.

Cheers, Vicent Marti

2011/3/10 Jonathan Nieder <jrnieder@gmail.com>:

Show 42 quoted lines

> Hey Vicent et al,
>
> Vicent Marti wrote:
>
>>                                                           there have
>> been proposals to merge parts of libgit2 into the original Git client;
>> however, this is not one of our priorities (we are designing git.git
>> to be embeddable in Git backends and GUI programs), and the library is
>> not yet stable enough for that kind of job. We'll see what the future
>> brings -- git.git would certainly benefit from some of our code, if
>> anything because it's (slightly) faster and cleaner than the original
>> implementation.
>
> I've been thinking that it would be interested to start this work
> early on, partially so that libgit2 and git.git can get to know each
> other better so to speak (which could help libgit2 along nicely and
> help git get past some old limitations, I think).  So I'm thinking of
> proposing stealing some of your code, with an eye toward eventually
> making git "just another libgit2 user", as a Google summer of code
> project idea.
>
> Is that a sane idea?  Is there any particular subset of the lib that
> would be an interesting place to start?  Do you forsee any obstacles?
> Do you know anyone who might be interested in mentoring such a
> project?
>
> Admittedly I'm not so familiar with libgit2 yet, so I'm willing to
> believe the answers might be no, no, yes, and no. ;-)
>
> The Google Summer of Code application deadline is this Friday
> (March 11) at 23:00 UTC.  If this does seem like a sane thing to do,
> it might be nice to put it on the ideas page at:
>
>  https://git.wiki.kernel.org/index.php/SoC2011Ideas
>
> Thanks for your work.
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Nguyen Thai Ngoc Duy· Mar 10, 2011, 11:39 UTC · re: Vicent Marti · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

On Thu, Mar 10, 2011 at 6:33 PM, Vicent Marti <tanoku@gmail.com> wrote:

> So, personally, I don't know anybody interested on mentoring *that*
> specific task, but I'm certainly interested on mentoring a "help
> complete libgit2" task: the earlier we stabilize the library, the
> earlier tasks like this one will be viable. Maybe on the next SoC? :)

Speaking of which, how complete is libgit2 compared to git? What are the significant missing pieces?

-- 
Duy

Vicent Marti· Mar 10, 2011, 12:56 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Hey,

On Thu, Mar 10, 2011 at 1:39 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

> Speaking of which, how complete is libgit2 compared to git? What are
> the significant missing pieces?

You can see the key features we are lacking in the SoC2011 ideas wiki:

https://git.wiki.kernel.org/index.php/SoC2011Ideas

Cheers, Vicent

Ramkumar Ramachandra· Mar 13, 2011, 17:11 UTC · re: Vicent Marti · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Hi Vincent,

Vicent Marti writes:

> You can see the key features we are lacking in the SoC2011 ideas wiki:
> 
> https://git.wiki.kernel.org/index.php/SoC2011Ideas

I thought we should de-couple both ideas and put up the idea of getting libgit2 merged on the wiki too: in the process, I've reworded things a bit. Please revert these changes if you think they're undesirable.

Thanks.

-- Ram

Jonathan Nieder· Mar 10, 2011, 11:55 UTC · re: Vicent Marti · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Hi again,

Two quick notes.

Vicent Marti wrote:

Show 5 quoted lines

> I think that right now it would be a quite daunting task to start
> replacing parts of git.git with libgit2. The architecture changes
> required would be quite significant, because of the way that git.git
> and libgit2 are designed (Unix-only, non-reentrant/cross-platform,
> reentrant)

(Side note: git actually can be built with MSVC, though the build process might be unfamiliar. See compat/vcbuild/README for details.)

> On top of that, the API for the library is not
> yet stable, so that integration may end up being kind-of-wasted work.

This is precisely why I want to see attempts at using it starting soon, whether as a student project or not: it would be a bad thing if git reveals assumptions or limitations in the API requiring major rework after the API has already solidified.

> So, personally, I don't know anybody interested on mentoring *that*
> specific task, but I'm certainly interested on mentoring a "help
> complete libgit2" task

Sounds good to me. ;-)

Thanks for explaining. Jonathan

Junio C Hamano· Mar 10, 2011, 19:27 UTC · re: Jonathan Nieder · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 5 quoted lines

>> I think that right now it would be a quite daunting task to start
>> replacing parts of git.git with libgit2. The architecture changes
>> required would be quite significant, because of the way that git.git
>> and libgit2 are designed (Unix-only, non-reentrant/cross-platform,
>> reentrant)

How big a performance penalty does libgit2 have to pay to depart from many "we run once and let exit take care of cleaning up after us" patterns used in git.git primarily in order to avoid the housekeeping cost?

Vicent Marti· Mar 11, 2011, 12:22 UTC · re: Junio C Hamano · lore

Re: Using libgit2 code in git.git as a Google Summer of Code project?

Hey,

On Thu, Mar 10, 2011 at 9:27 PM, Junio C Hamano <gitster@pobox.com> wrote:

> How big a performance penalty does libgit2 have to pay to depart from many
> "we run once and let exit take care of cleaning up after us" patterns used
> in git.git primarily in order to avoid the housekeeping cost?

It's not significant. We try to use custom memory allocation wherever possible, and the most complex structures (interdependencies in parsed objects from the DAG) are internally garbage collected, so we don't do any unnecessary free's. We try to offset the cost of 'proper' memory management by using smarter/more performance tuned algorithms. So far, some stuff ranges from varying degrees of faster-than-git (see: new revision walker, index writing, streaming loose object writes) to slightly slower (see object parsing :/).

We are working on it. Performance is our main concern.

Cheers, Vicent