Updated interop and new external API design

[tclem]

This is a significant update to libgit2sharp that includes these features:

• Updated external API (using this gist as a guideline). The design focus for the API has been discover-ability, making the repository as the root aggregate object and fluent interfaces where possible.
• Updated interop with C code with a focus on using marshaling instead of unsafe code.
• Repository is the only IDisposable object and a RepositorySafeHandle has been created to ensure proper clean up in any situation.
• All GitObjects (Commit, Blob, Tag, Tree) should now eager load their data and should not hold onto a C pointer as git_object_close() is immediately called after construction. Nested properties like the parents of a commit are to be lazy loaded and doing so requires a new lookup of the object in the repo.
• Only implementing high level external API. Advanced API usage like raw reads and writes will come later if at all.
• Separate .net 3.5 and .net 4.0 projects and assemblies are now being generated. (Silverlight and WP7 assemblies are in the works).
• Solid test suite and some new test helpers like the disposable TemporaryRepositoryPath object.

[vmg]

This is bongos, Tim. <3

[nulltoken]

Wow. Looks quite nice! I'm going to review this shortly.

Thanks a lot :)

[txdv]

Em, you should have taken a look at the devel branch of libgit2sharp, it was far more advanced.

[txdv]

Well, instead of using all the defined structs you just used IntPtr.
Unsafe code was earlier needed in order to access some of the private fields easier, since there were no getter methods for some of the struct fields. Basically we could use the devel branch, get rid of most of the struct definitions and use IntPtr now, because the libgit2 api basically has a getter and setter for everything.

Now you removed the generator code. I don't know bro, if you really wan't to maintain every single API change by hand, this might not bother you, but I would strongly suggest just adjust it. It is quite a hack, but it makes your life easier. I see you just used the earlier NativeMethods.cs and adjusted it. Well THAT one was generated by the generator. It really made the transition between big API changes fast and easy. After the "big" API changes I needed like 2 hours to adjust the C# code to work again.

And you basically got rid of the Core, the core was meant to provide an C# interface to the "naked" C api, and the main lib would use the core in order to create POCOs, so it would be save/safer. It was basically an OOP mirror of the base C API.

All in all, I like the idea of moving to more marshaled code, but I'm not so fond of the rest. Especially that this comes out of nowhere, even though I provided some contacts in the readme, shows that you just did what you thought was right without discussing with anyone else. I appreciate the work, but a little bit of collaboration wouldn't have hurt.

[nulltoken]

@tclem : Applied! That was an awesome proposal. Keep them coming :)