The C functions git_config_backend_from_string and git_config_backend_from_values added in 1.8.0 are documented here and here, respectively. The documentation does not mention anything about their being private / internal-use functions. Other functions in sys/config.h are GIT_EXTERN and have default visibility. However, these two functions are merely extern and have hidden visibility. This makes it impossible to use them from a shared library (and, thus, impossible to use in pygit2).
Either the documentation should be updated to reflect that they are hidden symbols, or they should be made GIT_EXTERN like all other functions in that header. They are the only two functions in that header that aren't GIT_EXTERN. Much bigger hoops have to be jumped-through in order to have an in-memory backend without these functions (all the callbacks have to be implemented, and there are many), so my recommendation is to make these GIT_EXTERN.
I'm happing to post a pull request to make these GIT_EXTERN if that's the approved approach, but I didn't want to presume that's correct.
The C functions
git_config_backend_from_stringandgit_config_backend_from_valuesadded in 1.8.0 are documented here and here, respectively. The documentation does not mention anything about their being private / internal-use functions. Other functions insys/config.hareGIT_EXTERNand have default visibility. However, these two functions are merelyexternand have hidden visibility. This makes it impossible to use them from a shared library (and, thus, impossible to use inpygit2).Either the documentation should be updated to reflect that they are hidden symbols, or they should be made
GIT_EXTERNlike all other functions in that header. They are the only two functions in that header that aren'tGIT_EXTERN. Much bigger hoops have to be jumped-through in order to have an in-memory backend without these functions (all the callbacks have to be implemented, and there are many), so my recommendation is to make theseGIT_EXTERN.I'm happing to post a pull request to make these
GIT_EXTERNif that's the approved approach, but I didn't want to presume that's correct.