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

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

[Jonathan Nieder]

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

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

[Jonathan Nieder]

(resending since my last mail was dropped; sorry for the noise)
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

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

[Vicent Marti]

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>:
> 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
>

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

[Nguyen Thai Ngoc Duy]

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

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

[Vicent Marti]

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

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

[Ramkumar Ramachandra]

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

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

[Jonathan Nieder]

Hi again,

Two quick notes.

Vicent Marti wrote:

> 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

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

>> 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?

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

[Vicent Marti]

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