Migrate to AutoGen solution

[mcdis]

Hi! What you think about to move to the autogen over *.h solution? Look to ffmpeg and sharpDx to the reference:

• https://github.com/sharpdx/SharpDX
• https://github.com/Ruslan-B/FFmpeg.AutoGen

Just provide slim and clean wrapper over natural libgit2

[ethomson]

I think that there's two different questions in this issue:

What you think about to move to the autogen over *.h solution?

What's the advantage of doing this over the hand-crafted solution that we have in place today? If this were a greenfield project, then the question of binding things manually or using some sort of autogenerator seems reasonable, but burning what we have down and starting over, hoping that the autogenerator matches the quality of what we have doesn't seem like an obvious win.

Just provide slim and clean wrapper over natural libgit2

That's a different proposition. We could publish the binding itself as a public API, basically break the core out into its own library that was usable by people who didn't want the LibGit2Sharp object model on top. But this is something that could be done today and is independent of how the core is created.

[mcdis]

@ethomson, split the core into the object model and the raw bindings are the bright idea.

Sometimes I can solve my typical task in "one line just" use the object model, but sometimes that's not enough and I need some plan B.

So wrapped libgit2 (public api) is a good choice.

For example, I need to load the public/private ssh key from my provider and I can use git_cred_ssh_key_memory_new but in sharp gitlib2 there is no way to do it.

About autogen...It can be used to automate the api wrapping into NativeBinaries. If you do it manually then libgit2 community do it twice...first time in C/C++ in the original and then duplicate the job in C#.

Missing functionality (not all funcs are wrapped) as the result

[mcdis]

https://github.com/xoofx/GitLib.NET