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.
Attachment:
signature.asc
Description: This is a digitally signed message part