Add support for push options
With libgit2/libgit2#6439 having been recently merged, this PR attempts adding support for push options to pygit2.
While the basic code change (d387941a309804ac7bc198be4d34e4086204258f) is fairly trivial, I had to jump through some other hoops to get it to work. Here is a summary of how this PR reached its current form:
- First, I need a libgit2 version that supports push options. Let's build it!
- Oh no, push options only work in libgit2's
masterbranch, not in libgit 1.7.2, which is the latest version that pygit2 currently works with. - Okay, let's hack around the current requirement for libgit2 1.7.x in pygit2's
masterbranch. (These changes are not included in this PR.) - This should be easy now, just turn a list of strings into a
git_strarrayand voilà. - Oh no,
StrArrayis only able to allocate a newgit_strarraystructure, how do I assign a list of strings to an existinggit_strarraythat is a member of another structure (git_push_options)? - Okay, let's add something reusable that can be used for this purpose.
- Done, now we can finally add support for push options :rocket:
So here we are:
- ed3a6b22797214d60e5e2a5f82f49aa257ce6c5c proposes a slight change in the way
StrArrayis used, to make the cases where a pointer to an allocatedgit_strarraystructure is passed to a libgit2 function slightly more readable (IMHO, of course), - 2c8fc47a377f62ced340372eb6f03e9e48386b94 adds a new method to
StrArraythat enables assigning a list of strings to an existinggit_strarraystructure (I deliberately avoided naming the methodcopy_to()because FFI scoping rules still need to be adhered to), - d387941a309804ac7bc198be4d34e4086204258f actually adds support for push options, using the
StrArray.assign_to()method added by the previous commit.
There is one more pitfall: I don't have any bright ideas for testing push options using the test infrastructure currently existing in the pygit2 repository. Hook support for libgit2 has been in the making for a few years now (libgit2/libgit2#4620) and server-side hooks cannot be defined for a GitHub repository (and even if this was possible, the test would need to examine some sort of an artifact created by the server-side hook, as it is done in the relevant libgit2 tests), so the only option I can think of is firing up a local Git daemon for this purpose during pygit2 tests. It's all doable, of course, but I thought it is prudent to wait for initial feedback on this proposal before going any further.
I would be happy to rework any part of this PR - it just felt that the additions proposed here might be useful in other similar cases in the future and it is always easier to discuss specific proposals than high-level ideas.
Thank you in advance for taking a look!
Fixes #1126