index: map git_index_conflict_add

[eantoranz]

map libgit2's git_index_conflict_add() as Index.add_conflict().

[eantoranz]

Interesting that it failed for macos (and that the feedback already tips that it might be a problem in libgit2).

[eantoranz]

Is there something to do with the centries after using them in git_index_conflict_add()?

[jdavid]

Reading cffi's documentation, centries will be garbage collected, so there is nothing to do with it.

[jdavid]

Interesting that it failed for macos (and that the feedback already tips that it might be a problem in libgit2).

What do you mean? I don't see a clue about libgit2 here:

        conflict = index.conflicts['conflict.txt']
>       assert conflict[0].id == ancestor_blob_id
               ^^^^^^^^^^^^^^
E       AttributeError: 'NoneType' object has no attribute 'id'
test/test_index.py:331: AttributeError

[eantoranz]

Interesting that it failed for macos (and that the feedback already tips that it might be a problem in libgit2).

What do you mean? I don't see a clue about libgit2 here:

It is not me who tipped about libgit2 being the culprint. It's feedback from the failed test, actually:

=========================== short test summary info ============================
SKIPPED [1] test/test_credentials.py:191: Requires proxy at port 8888
SKIPPED [1] test/test_repository.py:741: Requires proxy at port 8888
XFAIL test/test_nonunicode.py::test_nonunicode_branchname - probably a bug in libgit2 for non-linux platforms <==== HERE
FAILED test/test_index.py::test_add_conflict - AttributeError: 'NoneType' object has no attribute 'id'
====== 1 failed, 524 passed, 2 skipped, 1 xfailed, 10 warnings in 29.74s =======
Error: Process completed with exit code 1.

And given that the other platforms pass having the exact same code on pygit2 (and not much room for behavior differences there), I can only assume that the call to libgit2's git_index_conflict_add inside Index.add_conflict here is providing a NULL value where it is actually not expected. So... I think the description from the tests feedback pointing at libgit2 makes sense in this context. Am I missing something?

Just in case, what should be the right way to handle this? Should I go into libgit2, find the root cause of the test failure there, fix it and create a PR? It could get tricky given that I do not have a mac at hand so all I could do is just read code and try to make some (theoretical) sense as to why it might be failing.