As happened in support request https://github.com/libgit2/libgit2/issues/3963 it can be easily overseen,
that push returns True, when the remote has installed a hook that denies the commits.
In Python versions older than 3.2 hasattr is not robust as it masks real
errors. And usually is not efficient as a call to hasattr is often
followed by another call to getattr. It is best to avoid using it
completely.
See https://docs.python.org/3/whatsnew/3.2.html#other-language-changes
This was implemented for clone, but not for fetch or push, so it was
deleted during the conversion, which shows why we need to unify these
callback structures.
This represents what's going on much better than the remnants from the
older methods. What we do is pass a list of callbacks to libgit2 for it
to call, and they are valid for a single operation, not for the remote
itself.
This should also make it easier to re-use callbacks which have already
been set up.
These are only needed in C code. With Python files the signatures are
automatically generated. The only drawback is the return value is not
included in the signature, so document it in the body of the docstring.
In the online documentation to Pygit2 it was not visible that (some of)
the parameters to Remote.fetch() and Remote.push() were optional. Fix
this. (I'm not sure if the way I did it is the idiomatic way of marking
a parameter optional in Python docstrings.)
We need to keep hold of the strings which we create. We must also hold
on to the array of strings which we assing to our git_strarray.
We were not doing the latter, which meant that our strings may have been
freed too early, leaving us with with memory access errors (though often
not leading to a crash due to the custom allocator in python).
As we need to keep hold of two/three pieces of information, this looks
like a good place to introduce a context manager. This allows us to
keep these pointers alive without burdening the call sites with a return
of multiple objects they have no use for.
Move to use git_remote_push() instead of doing the steps ourselves. We
also change to accept a list of refspecs instead of just the one refspec
for the push method.
As part of this, we no longer error out if the server rejected any
updates, as this is a different concern from whether the push itself
failed or not. We do still error out if we attempt to push non-ff
updates.
Apart from the usual API changes, we now need to introduce the concept
of whether we still own the C object underneath our Repository and
Remote objects.
When using the custom callbacks for repository and remote creation
during clone, we pass the pointer and thus ownership of the object back
to the library. We will then get the repository back at the end.
We return the object which was handed to us rather than opening the
repository again with the local path as there is now a much higher
chance that the cloned repository does not use the standard backends.
This lets us look up remotes by name, which is not possible by just
returning the list of remotes.
Move remote creation to Repostiory.remotes.create() and keep the old
Repository.create_remote() for compatibility, delegating to this new
way.
Existing code should keep working, but this moves us towards what we'd
need for a better interface in 0.22 which makes remote renaming and
deleting work with a name rather than an instance and would make sense
to exist as part of an Remote.remotes object.
When setting the callbacks fails, we want to clear self._self_handle so
we don't leak a pointer to ourselves.
The current code used a 'finally' clause which clears it
unconditionally, which means that by the time the fetch starts, we have
no guarantee that the handle will be valid.
Replace that with an except and re-raise to make sure we only clear it
here if there was an error.
Renaming a remote in pygit2 has been done via Remote.name= up to now,
but this is inherently unsafe, as it provides no way to pass up the
refspecs that libgit2 was unable to remap.
In fact, if there ever was such problem, we would have segfaulted.
libgit2 now provides a much more direct way of getting back the results,
so expose it as the return value of Remote.rename(). This also removes
the hint that a rename might be something that happens only to the
in-memory structure.
Reconcile the changes between the ffi changes upstream with the changes
to libgit2 in the dev branch.
Conflicts:
src/config.c
src/options.c
src/refspec.c
src/remote.c
The C API expects a non-NULL new name and raises an assertion if we
don't protect against such input, so let's guard against falsy values,
which also takes care of the empty string, which is also not valid
input.
Pass the contents of the buffer containing the git_oid to bytes() so
build a raw representation of its contents. Using bytes(ffi.buffer(...))
returns the representation of the buffer.
