-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid internal git-buf API where possible #344
Conversation
Move them before git2r headers, use angle-brackets to differentiate public headers, and remove some extraneous includes. Signed-off-by: Elliott Sales de Andrade <[email protected]>
Signed-off-by: Elliott Sales de Andrade <[email protected]>
This reduces the need to use internal libgit2 functions. Signed-off-by: Elliott Sales de Andrade <[email protected]>
Signed-off-by: Elliott Sales de Andrade <[email protected]>
The public API is to use the `.ptr` struct entry directly. Signed-off-by: Elliott Sales de Andrade <[email protected]>
Signed-off-by: Elliott Sales de Andrade <[email protected]>
Thanks for fixing the git-buf usage and the libgit2 headers. I have a question regarding the angle-brackets. They affect the search path of the C pre-processor and since libgit2 is bundled within git2r, I'm curious about why this change? |
Technically they're both implementation defined, but in practice (gcc & msvc), the only difference is that quotes checks the current directory first (followed by The change is mostly a cosmetic one; when I see the angle brackets, I think it's external. Now, in this case it's not actually external, but it helps keep that connotation at least. |
Thanks |
The git-buf API is mostly internal to libgit2. Where an equivalent public API exists, this PR changes to those functions instead. This reduces the chances of breaking changes when updating libgit2 as there is less dependency on internals.
This PR is based on #336, so it looks a bit larger than it really is. The individual commits should be relatively straightforward though.