Idea: Separate Low Level LibGit2 Wrapper and Higher Level Convenience Classes

Empieza leyendo el LibGit2Sharp/Core wrapper existente y el área NativeLibs; después, revisa el enfoque propuesto con CppSharp y las definiciones de la API nativa de libgit2. El trabajo se considerará completado cuando haya un límite de paquete acordado, un plan de generación y mantenimiento, y un alcance claro para las APIs de bajo nivel y de conveniencia.

Looking at the pace of this repository it seems due to the lack of contributors it almost appears that there is not much happening on this library and it is not really in a production ready state.

Git/LibGit2 are advancing fast and obviously it is hard to keep up the pace providing a full .net flavor on top of that.

Hence I was thinking of the following: What if there would be two packages around libgit2sharp:

1. libgit2sharp.Internals, libgitsharp2.Core or reuse the existing libgit2sharp.NativeLibs: which is a very low level wrapper around the C-API of libgit2. This whole wrapper would be auto-generated using the structs and function definitions of the native lib. It just allows you to inconviniently use the C-API in the .net world. This library should be almost instantly up-to-date with the native libgit2 due to its automatic build and code generation nature. It allows everyone who is advanced enough to use low level APIs of libgit2. Also if APIs are not yet exposed on the higher level library (point 2) you might be able to call some low level functions if you know how to handle it. In short, it is likely everything in https://github.com/libgit2/libgit2sharp/tree/master/LibGit2Sharp/Core but publicly exposed for users who are capable of using such low levels as autogenerated code + some manual helpers maybe to make marshalling easier. We could use https://github.com/mono/CppSharp for this. It is well maintained and used.
2. libgit2sharp which provides the convenience APIs on top of the point 1 library which has proper native memory management. Nice APIs to interact with everything which needs time to design and implement manually. This library will likely be a bit slower to be up-to-date with the native lib because it needs manual development and organization.

We are concerned to use libgit2sharp in new projects due to its nature of not being maintained and uptodate. This implies risk of not getting bugfixes (feature and security wise) or new functionalities which are added to libgit2 in fast pace. I looked at how most .net tools currently interact with git and they seem to mostly rely on calling the git.exe and parse the outputs (I checked Visual Studio, Fork, GitHub Desktop and some other tools to evaluate how they do it) so we are left to either develop again an own framework for us, or rely on libgit2sharp which is struggling.

Let me know what you think of such an idea?