{"thread":{"id":"28271","subject":"[GSoC 2011] libgit2: final report","startedAt":"2011-08-31T21:00:00Z","lastAt":"2011-08-31T21:00:00Z","messageCount":1,"participants":["Carlos Martín Nieto"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174643","messageId":"1314824402.3680.95.camel@bee.lab.cmartin.tk","threadId":"28271","inReplyTo":null,"subject":"[GSoC 2011] libgit2: final report","fromName":"Carlos Martín Nieto","fromEmail":"carlos@cmartin.tk","sentAt":"2011-08-31T21:00:00Z","receivedAt":"2011-08-31T21:00:00Z","isPatch":false,"sender":{"key":"carlos@cmartin.tk","avatar":"https://gravatar.com/avatar/956bfe8371004f2960febf266a6af789f60cdc01fbae48bb151ad4c9b532c3a2?d=mp&s=160"},"body":"Hello all,\n\nGSoC is finished and I'll send the proof of work to Google shortly. Many\nthanks to everyone who helped me along the way.\n\nSo? How did it go? Unfortunately I wasn't able to do everything that was\nin the (quite optimistic) original plan as there were some changes and\nadditions that had to be done to the library in order to support the new\nfeatures (the code movement in preparation for the indexer\n(git-index-pack) being the clearest example of this. The code has been\nmerged upstream and you want to look at examples of use, you can take a\nlook at my libgit2-utils repo[0] where you can find a functional\nimplementation of git-fetch (git-clone would be about 20 lines more, I\njust never got around to writing it).\n\n[0] https://github.com/carlosmn/libgit2-utils\n\nLet me give you a few highlights of what new features were added to the\nlibrary:\n\n _Remotes_\n\n  A remote (struct git_remote) is the (library) user's interface to the\ncommunications with external repositories. When read from the\nconfiguration file, it will parse the refspecs and take them into\nconsideration when fetching. With the most recent changes, you can also\ncreate one on the fly with an URL. The remote will create an instance of\na transport and will take care of the lower-levels.\n\n_Transports_\n\n The logic exists inside the transports. Currently only the fetch part\nof the plain git protocol is supported, but the architecture is\nextensible. The code would have to live in the library, but adding\nsupport for plug-ins, as it were, would be an easy task.\n\n_pkt-line_\n\n The code for parsing and creating these lines is its own namespace, so\nthat it can be used for other transports. It supports a kind of\nstreaming parsing, as it will return the appropriate error code if the\nbuffer isn't large enough for the line.\n\n_Indexer_\n\n This is what libgit2 has instead of git-index-pack. It's much slower\nthan the git implementation because it hasn't been optimised yet as it\nuses the normal pack access methods. Currently the only user would be a\ngit-fetch implementation and that is still fast enough so it's not that\nhigh a priority.\n As a result of this work, the memory window and pack access code has\nbeen made much more generic.\n\n\n I plan to continue working on this project. The next steps are push\n(which has quite a few prerequisites, not least pack generation) and\nsmart HTTP support. The addition of the new backend should help make\ncode more generic. After that, SSH support should be a matter of\nwrapping the existing code up.\n"}]}