librelist archives

« back to archive

Introducing libgit2-glib

Introducing libgit2-glib

From:
Nacho
Date:
2011-08-12 @ 11:01
Hey guys,

I've been working on a binding library for GLib supporting as well
introspection,
meaning that you can use it too with vala, python and javascript for now.

The library it is still missing quite some features but some testing would
be great.

You can find it here: https://github.com/nacho/libgit2-glib

Some questions:

While working on it I am having some problems to understand some parts of
the API,

* what's the indexer for?

* I've seen that there is a git_index_entry, for what I can understand it
represents a
specific file. What's the point for having the status.h stuff if it is
suppose to be related
with a specific file? Can't it go into the git_index_entry?

* Also isn't it more or less the same what you want to do with tree.h and
index.h?

Probably I will come up with something else soon.

PS: I've seen that you manage flags using defines, isn't it easier/better
approach using enums?

Regards.

-- 
Ignacio Casal Quinteiro

Re: [libgit2] Introducing libgit2-glib

From:
Carlos Martín Nieto
Date:
2011-08-12 @ 13:58
On Fri, 2011-08-12 at 13:01 +0200, Nacho wrote:
> Hey guys,
> 
> I've been working on a binding library for GLib supporting as well
> introspection,
> meaning that you can use it too with vala, python and javascript for now.
> 
> The library it is still missing quite some features but some testing would
> be great.

Thanks for your work.

> 
> You can find it here: https://github.com/nacho/libgit2-glib
> 
> Some questions:
> 
> While working on it I am having some problems to understand some parts of
> the API,
> 
> * what's the indexer for?

When objects are put together in a packfile (.git/objects/pack/*.pack)
to save space, we need a way to know where the objects are. This is
accomplished by the .idx files, and just such a file is what the indexer
creates. IOW, it's git-index-pack.

> 
> * I've seen that there is a git_index_entry, for what I can understand it
> represents a
> specific file. What's the point for having the status.h stuff if it is
> suppose to be related
> with a specific file? Can't it go into the git_index_entry?

As the name suggests, git_index_entry represents an entry in the index.
Such an entry represents a file in a specific stage (and the file
doesn't necessarily need to exist on disc). A file may exist in the
index in several stages at the same time when a merge is going on, but
let's not worry about that now. The status code is relatively new and
there might be some code or structures that can be shared. However,
status is meant to compare the worktree with the index, and it probably
does need its own code.

> 
> * Also isn't it more or less the same what you want to do with tree.h and
> index.h?

In what way? There are no trees in the index (except for the tree cache
and that's something else). The index only deals with individual files.
Trees are built on-the-fly.

> 
> Probably I will come up with something else soon.
> 
> PS: I've seen that you manage flags using defines, isn't it easier/better
> approach using enums?

In an object-oriented language, sure, but in C, one method is not
inherently better than the other. For flags you need to manually set the
values anyway, so it doesn't save you any work. Bitfields are also an
option, but they only really work internally, as most structures are
opaque.

Cheers,
   cmn
-- 
Carlos Martín Nieto        http://www.cmartin.tk

"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI

Re: [libgit2] Introducing libgit2-glib

From:
Nacho
Date:
2011-08-12 @ 14:27
Hey,

thanks a lot for your answers.

Regards.

On Fri, Aug 12, 2011 at 3:58 PM, Carlos Martín Nieto <carlos@cmartin.tk>wrote:

> On Fri, 2011-08-12 at 13:01 +0200, Nacho wrote:
> > Hey guys,
> >
> > I've been working on a binding library for GLib supporting as well
> > introspection,
> > meaning that you can use it too with vala, python and javascript for now.
> >
> > The library it is still missing quite some features but some testing
> would
> > be great.
>
> Thanks for your work.
>
> >
> > You can find it here: https://github.com/nacho/libgit2-glib
> >
> > Some questions:
> >
> > While working on it I am having some problems to understand some parts of
> > the API,
> >
> > * what's the indexer for?
>
> When objects are put together in a packfile (.git/objects/pack/*.pack)
> to save space, we need a way to know where the objects are. This is
> accomplished by the .idx files, and just such a file is what the indexer
> creates. IOW, it's git-index-pack.
>
> >
> > * I've seen that there is a git_index_entry, for what I can understand it
> > represents a
> > specific file. What's the point for having the status.h stuff if it is
> > suppose to be related
> > with a specific file? Can't it go into the git_index_entry?
>
> As the name suggests, git_index_entry represents an entry in the index.
> Such an entry represents a file in a specific stage (and the file
> doesn't necessarily need to exist on disc). A file may exist in the
> index in several stages at the same time when a merge is going on, but
> let's not worry about that now. The status code is relatively new and
> there might be some code or structures that can be shared. However,
> status is meant to compare the worktree with the index, and it probably
> does need its own code.
>
> >
> > * Also isn't it more or less the same what you want to do with tree.h and
> > index.h?
>
> In what way? There are no trees in the index (except for the tree cache
> and that's something else). The index only deals with individual files.
> Trees are built on-the-fly.
>
> >
> > Probably I will come up with something else soon.
> >
> > PS: I've seen that you manage flags using defines, isn't it easier/better
> > approach using enums?
>
> In an object-oriented language, sure, but in C, one method is not
> inherently better than the other. For flags you need to manually set the
> values anyway, so it doesn't save you any work. Bitfields are also an
> option, but they only really work internally, as most structures are
> opaque.
>
> Cheers,
>   cmn
> --
> Carlos Martín Nieto        http://www.cmartin.tk
>
> "¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
>



-- 
Ignacio Casal Quinteiro