Hi there,
I'm the student working on the gsoc libfication project with Shawn and it

has reached the point where I need some feedback in order to decide

what to do next.
The project's goal was/is to change what is needed in GIT in order to make

it easier to use as library. This is useful for 'external'

applications which wants

to be able to perform GIT operations w/o having to fork-exec GIT process (and

also w/o having to parse git's programs output). Example of such applications

are language bindings and IDEs' plugins.
However, the need for this is not a consensus. Some disagree (Linus included

I think) and IIRC Junio has stated that he'd probably be against a stable API.
So, in order to make things simple and have a clear separation of what is

additional interface not needed by GIT we (Shawn and I) have decided to work

on a new library which uses git's low-level interface.
That library is called libgit-thin and currently it's capable of

revision listing,

commit parsing and some other things.
To demonstrate how to use the library, I've also written a python module which

exports to python all the library's functionality.
Now I need to know whether this' really useful to other people and if so, what

would be missing for you to start using it.
The project can be found at:
http://repo.or.cz/w/git/libgit-gsoc.git
Look into the 'libgit-thin' directory. Note that it's a fork of

Junio's tree, so if you have

his repository around do:
$ git clone --reference /path/to/junio/repo git://repo.or.cz/git/libgit-gsoc.git
A demo of the python's module is available here:
http://repo.or.cz/w/git/libgit-gsoc.git?a=blob;f=libgit-thin/pygit/demo....
Please, keep in mind that the library's code is still experimental and most of

the python module's code is untested.
It's also important to say that there's no much documentation

available, you'll have

to know a bit about git's implementation for this stuff to be useful for you...
[ message continues ]

The python module would really be useful to StGIT.  Currently, an

stgit commands typically has to fork several git commands at least,

and using library calls instead would surely help with the

performance.
I had a quick look at the current pygit API (as described in the

README), and I find the current revlist one somewhat confusing.  Why

using post-contructor methods, and not using named args in the

constructor itself ?
...  print commit.id()

... 
...                   count = 10,

...                   show_merges = true)

...  print commit.id()

... 
What do you think ?
Best regards,

--

Yann

-

Hi Yann,
 I think you're right, that'd be nicer.
 The problem is that the revlist operation accepts a lot of options,

and to change

all (or a big amount of them) would force one to build a very length list of

arguments.
 Currently we have just a few, but we'll add more in the future.
 Also, I think that it won't be that nice to play with include() and exclude(),

since you can call them more than once.
 I'm not sure whether in its current state the module (plus the library) is

useful for stgit.
 Please, feel to make questions and to ask for what'd be missing for you

to adopt it.
 I'm a quilt user and completely forgot that stgit is written in python. I'll

take a look.
 Thanks for your comments,
--

Luiz Fernando N. Capitulino

-

Nicer to use if the commands and their options originate from withing

Python.  But if Python parses arguments from somewhere else and passes

them on, the former interface leads to much cleaner code AFAICS.

Pasting together a named argument call piecemeal is not going to be

pretty, I should think.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

You just put all the arguments in a dict and use the ** syntax. And if you

already get the arguments in a dict from the parser, it's even nicer.
--=20

						 Jan 'Bulb' Hudec <bulb@ucw.cz>