Change refspec api #290

merged 5 commits into from Dec 2, 2013


None yet

3 participants

jplana commented Nov 25, 2013

New attempt to provide refspec API with pygit, now using the new functions in libgit 0.20

It will expose:

the attributes

  • fetch_refspecs
  • push_refspecs

returning a list of strings with the refspecs

the methods

  • set_fetch_refspecs([str])
  • set_push_refspecs([str])

setting a list of strings a new refspecs

@carlosmn carlosmn commented on an outdated diff Nov 25, 2013
@@ -95,8 +96,164 @@
+PyObject * get_pylist_from_git_strarray(git_strarray *strarray)
+ int index;
+ PyObject *new_list;
+ new_list = PyList_New(strarray->count);
+ for (index = 0; index < strarray->count; (index)++ ) {
+ PyList_SET_ITEM(
+ new_list,
+ index,
+ PyString_FromString(strarray->strings[index]));
carlosmn Nov 25, 2013 libgit2 member

We have to_unicode for this which works across verisions.

jdavid commented Nov 25, 2013

I think the API will be more intuitive if using a getset instead of a method, so:

refspecs = remote.fetch_refspecs
remote.fetch_refspecs = refspecs

Please update the documentation: docs/remotes.rst


jplana commented Nov 26, 2013

I fixed most of the issues here, except probably the most important, the API. I see one problem with your proposal, while this would work:

remote.fetch_refspecs = ['xxx:xxxx','yyyy:zzzz']

This would not produce the expected result:

remote.fetch_refspecs[0] = 'xxxx:xxxx'

which a user of the library might use, as this is correct:

print remote.fetch_refspecs[0]
>>> 'xxxx:xxxx' 

IMHO a list where you could do

remote.fetch_refspecs[0] = 'xxxx:xxx'
# or even

would be nicer, though I would leave it for a future PR (comments on this are welcome)

BTW I don't know if the attribute get_refspec makes sense anymore as the user can just "iterate" all refspecs using the refspec_count total but won't know if it's either a push or fetch refspec, not very useful.

jdavid commented Nov 26, 2013

Then it should be Remote.get_fetch_refspecs() so the API is symmetric.

jplana commented Dec 2, 2013

I think that fixes all the comments, adding better error treatment and making the API symmetric.

jdavid commented Dec 2, 2013

After merging I get this error:

$ python build
x86_64-pc-linux-gnu-gcc -pthread -fPIC -I/usr/local/include -Iinclude -I/usr/include/python2.7 -c src/remote.c -o build/temp.linux-x86_64-2.7/src/remote.o
src/remote.c: In function ‘Remote_set_fetch_refspecs’:
src/remote.c:503:1: error: expected declaration or statement at end of input
error: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1
jplana commented Dec 2, 2013

Upssss. Sorry about it.

@jdavid jdavid merged commit 6050ae0 into libgit2:master Dec 2, 2013

1 check passed

Details default The Travis CI build passed
jplana commented Dec 2, 2013

Thanks a lot for your patience :-D

jdavid commented Dec 2, 2013

Thank you for contributing.

Note I have fixed error handling. The Python functions already set an exception whenever there is an error, so you only need to set the exception for anything else.

jplana commented Dec 3, 2013

I see the changes, thanks a lot. Still learning how to do proper python exceptions :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment