librelist archives

« back to archive

[GSoC 2011] libgit2: final report

[GSoC 2011] libgit2: final report

From:
Carlos Martín Nieto
Date:
2011-08-31 @ 21:00
Hello all,

GSoC is finished and I'll send the proof of work to Google shortly. Many
thanks to everyone who helped me along the way.

So? How did it go? Unfortunately I wasn't able to do everything that was
in the (quite optimistic) original plan as there were some changes and
additions that had to be done to the library in order to support the new
features (the code movement in preparation for the indexer
(git-index-pack) being the clearest example of this. The code has been
merged upstream and you want to look at examples of use, you can take a
look at my libgit2-utils repo[0] where you can find a functional
implementation of git-fetch (git-clone would be about 20 lines more, I
just never got around to writing it).

[0] https://github.com/carlosmn/libgit2-utils

Let me give you a few highlights of what new features were added to the
library:

 _Remotes_

  A remote (struct git_remote) is the (library) user's interface to the
communications with external repositories. When read from the
configuration file, it will parse the refspecs and take them into
consideration when fetching. With the most recent changes, you can also
create one on the fly with an URL. The remote will create an instance of
a transport and will take care of the lower-levels.

_Transports_

 The logic exists inside the transports. Currently only the fetch part
of the plain git protocol is supported, but the architecture is
extensible. The code would have to live in the library, but adding
support for plug-ins, as it were, would be an easy task.

_pkt-line_

 The code for parsing and creating these lines is its own namespace, so
that it can be used for other transports. It supports a kind of
streaming parsing, as it will return the appropriate error code if the
buffer isn't large enough for the line.

_Indexer_

 This is what libgit2 has instead of git-index-pack. It's much slower
than the git implementation because it hasn't been optimised yet as it
uses the normal pack access methods. Currently the only user would be a
git-fetch implementation and that is still fast enough so it's not that
high a priority.
 As a result of this work, the memory window and pack access code has
been made much more generic.


 I plan to continue working on this project. The next steps are push
(which has quite a few prerequisites, not least pack generation) and
smart HTTP support. The addition of the new backend should help make
code more generic. After that, SSH support should be a matter of
wrapping the existing code up.