librelist archives

« back to archive

libgit2 state

libgit2 state

From:
Andrius Bentkus
Date:
2011-02-26 @ 14:14
Hello fellow libgit folks,
I have tracked the libgit2 development for a while now but it was always
seemed to me like it was a dead project after the initial gsoc. Now I see
that it is pretty much alive (thanks to the changelog cast in which I heared
about the presense of it on github).
It's nice to hear that there is some kind of financial support behind (from
the changelog cast), but I would like to know how the git 1.x guys are
related to this project and if they are somehow interested in it and
supporting it?
Clearly the progit author, which sounds like a big git player in the git
world, is behind it. But if I do a simple sloccount over git and libgit2...
the later has 5% of the the former so I would like really to hear from you
people what the state of the project is and how it relates to git1.

Re: libgit2 state

From:
Andrius Bentkus
Date:
2011-03-02 @ 18:16
Hey guys, I wanted to know if the library already exposes some means to
retrieve references?

Re: [libgit2] Re: libgit2 state

From:
Vicent Marti
Date:
2011-03-02 @ 18:23
https://github.com/libgit2/libgit2/blob/refcount/src/git2/refs.h

This is new References API. It's still experimental, but it'll be
merged into master very soon. It not only supports retrieving
references, but also creating, modifying, renaming and deleting of
both packed and unpacked references. You can even create the
packed-refs file yourself.

Hope this is of some use.

Cheers,
Vicent Marti



On Wed, Mar 2, 2011 at 8:16 PM, Andrius Bentkus
<andrius.bentkus@gmail.com> wrote:
> Hey guys, I wanted to know if the library already exposes some means to
> retrieve references?
>
>

Re: libgit2 state

From:
Andrius Bentkus
Date:
2011-03-02 @ 18:30
Sorry for the premature post.
I'm interested if there exists some way to retrieve all references, looking
at the API I just see a way to create new references, but no way to actually
go through the existing once.
In general it seems to me that the api exposes a lot of ways
store/create/write/read stuff, but I always need a oid to begin with.
I just want to retrieve a list of refs, branches, commits with no oid to
begin with, what advise could you give me?

On Wed, Mar 2, 2011 at 7:16 PM, Andrius Bentkus
<andrius.bentkus@gmail.com>wrote:

> Hey guys, I wanted to know if the library already exposes some means to
> retrieve references?
>
>

Re: [libgit2] Re: libgit2 state

From:
Vicent Marti
Date:
2011-03-02 @ 18:34
Hey,

you don't really need an OID -- just a reference name. One quick way
would be to fetch the "HEAD" reference. That's assured to be there,
and it'll point to the current branch reference in "refs/heads/" (just
resolve it using git_reference_resolve()), and the head will give you
the OID of the latest commit. From there, you can use the Revwalking
API to traverse the repository, getting commits, trees, blobs and
whatnot.

You are right that it would be nice to have a way to list all
references that are not the head (i.e. all the branches). I'll get to
work on that.

Cheers,
Vicent Marti



On Wed, Mar 2, 2011 at 8:30 PM, Andrius Bentkus
<andrius.bentkus@gmail.com> wrote:
> Sorry for the premature post.
> I'm interested if there exists some way to retrieve all references, looking
> at the API I just see a way to create new references, but no way to actually
> go through the existing once.
> In general it seems to me that the api exposes a lot of ways
> store/create/write/read stuff, but I always need a oid to begin with.
> I just want to retrieve a list of refs, branches, commits with no oid to
> begin with, what advise could you give me?
> On Wed, Mar 2, 2011 at 7:16 PM, Andrius Bentkus <andrius.bentkus@gmail.com>
> wrote:
>>
>> Hey guys, I wanted to know if the library already exposes some means to
>> retrieve references?
>>
>
>

Re: [libgit2] libgit2 state

From:
Vicent Marti
Date:
2011-02-27 @ 11:34
Hey Andrius,

thanks for your interest. libgit2 is indeed alive and kicking. Git
core is of course interested on the library (at least that's what I
gathered from our exchanges on the Git mailing list), and 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.

Regarding the status of the project, it's coming along pretty nicely.
Right now we have most of the plumbing commands for handling a local
repository, and our immediate goal is to get started on the networking
(sending and receiving packs, etc). The massive difference between
LOCs is because we're only implementing plumbing commands: we are
developing a Git library, not a Git client.

I hope that answered some of your questions.

Cheers,
Vicent Marti



On Sat, Feb 26, 2011 at 4:14 PM, Andrius Bentkus
<andrius.bentkus@gmail.com> wrote:
> Hello fellow libgit folks,
> I have tracked the libgit2 development for a while now but it was always
> seemed to me like it was a dead project after the initial gsoc. Now I see
> that it is pretty much alive (thanks to the changelog cast in which I heared
> about the presense of it on github).
> It's nice to hear that there is some kind of financial support behind (from
> the changelog cast), but I would like to know how the git 1.x guys are
> related to this project and if they are somehow interested in it and
> supporting it?
> Clearly the progit author, which sounds like a big git player in the git
> world, is behind it. But if I do a simple sloccount over git and libgit2...
> the later has 5% of the the former so I would like really to hear from you
> people what the state of the project is and how it relates to git1.

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

From:
Jonathan Nieder
Date:
2011-03-10 @ 10:18
(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