 Hello. My name's Russell Belfer. I work at GitHub on LibGit2. And a couple of folks have asked to hear a little bit more just about the state of LibGit2, because some of you may be aware that we are actually not at a 1.0 release yet. So the question that I've probably gotten the most during this conference has been, when will core Git be rewritten on top of LibGit2? And the answer to that, in case there's any question, is never. We serve different masters, right? Everything that Vincent talked about when he was speaking is all the things that core Git does that make it not so useful in a server setting are actually good things for it to be doing, right? There it helps it run quickly. They solve the problem in as efficient way as possible for executing a particular command. And that's what they should be doing. And so there's some hope that at the future we may share code modules. For example, if there's a fantastic merge engine or a fantastic file similarity detection or whatever it might be, then we may share some code. But they are independent projects. And you should not be thinking of them as somehow while one will replace the other. So if you hang on just a moment. There we go. So what is the state of LibGit2? So LibGit2 is very close to a 1.0 release. Anything that you want to do, typically with a Git repository locally, you can probably do almost anything. You can read and write objects. You can create trees, commits. You can manipulate the index. Essentially, anything that you would do with references, objects, configuration settings should all be available to you. We support fetch and push over HTTP and Git with SSH. There's a SSH pull request that's probably ready to be merged in the next couple weeks or so, which should give us fairly good network support. On Windows, we support Win HTTP. So it's nicely integrated with the rest of the system. A pretty good experience. We support diff status with ignores and CRLF filtering, rename detection, a pretty wide range of things there. History walking, ref logs, branching, rev bars, check out. Provided there are no conflicts. Stash, notes, sub modules, all of the access to the object database to references and to configurations actually support pluggable storage backends. So out of the box, LibGit2 ships with your traditional file system backends for dealing with Git repositories, as you know and use all the time. But you can actually create your own back end objects to store those however you want to. And there's some experimentation with some alternatives there. It also supports nicely configurable caching. So you can say, oh, I'd like to keep cache trees and memory. So as you do have these long live processes, you can make some intelligent decisions about what you'd like to save in memory so that things can be more efficient in the long run. So no, I actually just have notes. So sorry, I could put this up in a state of LibGit2 document in the LibGit2 repo. But right now, I'm sorry, I just have notes. Sorry, this is a little last minute. So I guess the flip side of what LibGit2 can do is what can't it do, what's missing. So probably the biggest thing that's missing is we do not have a merge engine that is complete. There is merge in progress. Some beginning parts of it have been merged. And then there's other stuff that's on the way, but it is not done. And as a result, you can't really do pull because we don't have a good way of merging in things when you pull. We also don't have blame right now. That's also work in progress. This is, in case it's not incredibly obvious to everyone, LibGit2 is, there we go. In case it's not obvious to everyone, LibGit2 is fully open source. So you can actually just go on to GitHub, LibGit2 organization, LibGit2 project, and see all the pull requests in progress. Comment on them. Say, I don't like the way this API is designed. And we actually care. There are some things that are some other small things that are still missing. Our status doesn't currently support rename detection in status. That's probably on the way. There's lots of little things. Diff doesn't support word diff or function context. You can't do recursive clones right now. Some ref manipulation doesn't automatically write ref logs. And there's a bunch of things that you would have to potentially do manually if you were looking at logs or things like that. But it's pretty good. There are a few known bugs, although they're pretty small. A lot of, if you're running on case and sensitive file systems, or particularly if you're running on case and sensitive but case preserving file systems, that is evil. And well, not evil. It's very convenient, but it is not so convenient for Git. And then on Windows, there's still some oddities with sim links and things like that. But for the most part, it is pretty good. And I'll actually talk later about ways that you can help with those very things. So Libgit 2 runs on a lot of platforms, right? So Linux, Mac OS, Windows, Solaris, a bunch of BSDs, Amiga OS, for those of you who are Amiga fans. Most of the operations across this platform, many of the operations are thread safe. That is not everything, but we've certainly concentrated on access to the objects. And so you can have multiple threads that are at least looking up and reading the data in the repository. And that seems to work pretty well across threads. Again, we'll probably get better over time, but mostly through you all using it and writing your own Git applications. So bindings, most people don't write C, apparently. I don't know why, but. And so there are bindings in a lot of different languages. Libgit 2 Sharp is probably the most advanced of the bindings right now. It covers almost 100% of the functionality that is in Libgit 2. And it is a very idiomatic binding. So if you are a C Sharp fan, it should feel very natural. Rugged is the Ruby binding. It is further behind, but it is actually, well, Rugged and Objective Git, which is the Objective C binding, and Pygit 2, which is the Python binding. Those three, none of them are complete bindings, but actually they're all fairly active. And a lot of the work that they've been doing recently have driven API changes in the underlying library to make it actually easier for them to provide idiomatic support for Accessing Git that's natural to users of that language. In particular, I think that there's a couple of the Pygit 2 folks who are here. I think that Pygit has been doing a lot of work on trying to become more idiomatic so that it feels more natural to the language users. So the last thing, really, that I have to say is if you're interested in Libgit 2 and you'd like to get involved, it is a fairly easy project to get involved with. Because you can access it from so many languages, if you're interested in looking at Git data, manipulating Git data, you can probably pull down a binding in your language of choice and just start playing around. And to the extent that you do that and are willing to contribute back sample code, here's a little experiment that I did in this thing, that's amazing for us. Because that is how people use the library and learn to have fun with their Git repositories. And so anything that you do that you're willing to share is helpful. You're also certainly welcome to open issues, because I think it is still a young library and you will find them, and we like that. You're also very welcome to open PRs. Pull requests, Libgit 2 is a very, very typical open source project. We have, in any given month, we're likely to have 15 to 20 contributors. Lots of people will just fork it, open PRs, and the team. We really try to make a lot of effort to be very supportive. So it's a pretty easy project to get involved in. Actually, if you look at our readme, there's a section on good starter projects, if you want to start playing around with things. And I think most of the binding teams are also very receptive to people who want to come in and start finding small ways that they can enhance things or play around with it. So I don't know. If you have any questions, I'm happy to answer them. Sure. I noticed that you just, a few weeks ago, actually cut a release. We did. Which release? Yeah. Cutting milestones going forward. Yeah, so we had been on a pretty good track. And these things happen. So we were shooting for a release, basically last October as the Microsoft folks started getting more involved. And we started getting actually a little bit more ambitious, because the team of folks who were actively working in the library grew. We're like, oh, well, we'll shoot for a 1.0 release by the end of the year. These things happen anyhow. So we did just cut the 0.18 release. I think we are going to make an effort to do more frequent releases. We had been doing pretty well on every three to four months doing releases prior to that. And so hopefully we'll be at least back on that track if not more frequent. Our big thing has been, and as you may have noticed, if you looked at the differences between the last two releases, is we've tried to get all of the breaking API changes in now so that we can actually get to a 1.0 release where we won't break the API. And so that's been actually one of the big challenges for the project over the last six months as we've been kind of pushing in many breaking API changes. Hopefully it is resulting in a more consistent and standard API. So it should get us to a good place. But we welcome your free to open issues and say, you guys suck, please stop doing that. Or actually the release that did happen, I don't know if you followed it, but it was actually largely driven over an issue that was opened. I think by the PyGet folks just saying, hey, come on, it's time for a release. But it's fine. We're totally happy to have that. We had a little back and forth discussion. And ultimately tried to understand why having that particular tag was important and pushed it out. Anything else? OK, thanks for your time.