libgit2 / libgit2/libgit2sharp
Idea: Separate Low Level LibGit2 Wrapper and Higher Level Convenience Classes
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 3.5k
- Forks
- 925
- PR merge metrics
- No merged PRs in 30d
Description
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:
- 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.
- 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?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the existing LibGit2Sharp/Core wrapper and NativeLibs area, then review the proposed CppSharp approach and libgit2's native API definitions. Done would require an agreed package boundary, generation and maintenance plan, and a clear scope for the low-level and convenience APIs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, git
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100