Summer Of Code
Last year my application was selected by Google for their Summer of Code program, and before I tell you how wonderful the program is, I’ll show you one of the things I’ve done.
It’s a GIT binding for Python. So, you’ll have to know a little bit about them to understand the demonstration.
For example, say that you want to get some information about commit
4fbef206daead133085fe33905f5e842d38fb8da from Linus’ GIT tree, you could do:
>>> import pygit
>>>
>>> linux = '/home/lcapitulino/src/kernels/upstream/linux-2.6'
>>> repo = pygit.open(linux)
>>>
>>> id = '4fbef206daead133085fe33905f5e842d38fb8da'
>>> com = repo.lookup_commit(id)
>>>
>>> print com.id()
4fbef206daead133085fe33905f5e842d38fb8da
>>>
>>> print com.message()
nfsd: fix nfsd_vfs_read() splice actor setup
When nfsd was transitioned to use splice instead of sendfile() for data
transfers, a line setting the page index was lost. Restore it, so that
nfsd is functional when that path is used.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>
You can also, compare two commits.
>>> com1 = repo.lookup_commit(repo.head_commit())
>>>
>>> id = '4fbef206daead133085fe33905f5e842d38fb8da'
>>> com2 = repo.lookup_commit(id)
>>>
>>> if com1 > com2:
... print 'com1 is more recent'
...
com1 is more recent
>>>
[ For a complete demonstration click here ].
One of the good things about the binding is that it doesn’t fork()/exec() GIT processes. Instead, it uses a library which makes it fast and easy to deal with errors.
The goal of the project was to write a high-level library for GIT. The reason for this is that GIT’s own library is very low-level. It means that to understand how to use it you have to understand GIT’s internals, but even then the API isn’t stable and it’s hard to link against (since it was written to only link against GIT’s programs).
Currently, the standard way to create software which accesses GIT repositories is to fork()/exec() GIT programs. The main disadvantages of this approach are:
1. It can be a slow operation
2. It may not be easy to handle process execution
3. It’s not easy to deal with errors
4. There’s no flexibility
A well written library can solve all those problems. Besides that, in order to demonstrate the API usage and usefulness, I would write a binding for any high-level language. I chose Python.
The project was just wonderful. I’ve had a great time working on it. I’ve learned a lot about GIT, Python bindings and a little bit more about C and general program design. My mentor is just a great person. He was always patient and taught me everything I know about GIT and its internals.
However, I’m not very proud of the final result. Firstly, I was very excited about the project as a whole and my expectations were quite high. I thought it would be merged upstream or at least would attract the attention of lots of interested people.
But that wasn’t exactly what happened. The main problem is that at the end of the project I had only a Proof-Of-Concept of the thing. Only a small amount of functions to extract information from repositories were written (plus the Python binding).
We did some successful experiments though, which showed us we were on the right track. For example, we made an initial port of one of the GIT graphical browsers, QGit. We’ve removed a big portion of its code (which was dedicated to handling GIT processes) and although some changes were needed, the library fell into place nicely.
But I still feel a bit frustrated for not getting the project up to a “production” level. Some people are still interested in it, I receive about two emails per month asking questions about the project… Which makes me feel a bit worse.
After thinking about it for some time, I concluded that the main problems were:
1. I thought the four hours per day I had would be enough
2. I didn’t expect to spend time as long as I did studying GIT and trying different designs
These are the reasons why I have decided not to participate this year (I still have only four hours per day). Maybe next year I’ll try again.
But it was a great project. I will never forget it.