pygit2 icon indicating copy to clipboard operation
pygit2 copied to clipboard

Add support for push options

Open kempniu opened this issue 1 year ago • 0 comments

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:

  1. First, I need a libgit2 version that supports push options. Let's build it!
  2. Oh no, push options only work in libgit2's master branch, not in libgit 1.7.2, which is the latest version that pygit2 currently works with.
  3. Okay, let's hack around the current requirement for libgit2 1.7.x in pygit2's master branch. (These changes are not included in this PR.)
  4. This should be easy now, just turn a list of strings into a git_strarray and voilà.
  5. Oh no, StrArray is only able to allocate a new git_strarray structure, how do I assign a list of strings to an existing git_strarray that is a member of another structure (git_push_options)?
  6. Okay, let's add something reusable that can be used for this purpose.
  7. Done, now we can finally add support for push options :rocket:

So here we are:

  • ed3a6b22797214d60e5e2a5f82f49aa257ce6c5c proposes a slight change in the way StrArray is used, to make the cases where a pointer to an allocated git_strarray structure is passed to a libgit2 function slightly more readable (IMHO, of course),
  • 2c8fc47a377f62ced340372eb6f03e9e48386b94 adds a new method to StrArray that enables assigning a list of strings to an existing git_strarray structure (I deliberately avoided naming the method copy_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

kempniu avatar Mar 18 '24 10:03 kempniu