This commit allows blobs to be constructed from implementatons of the
'RawIOBase' ABC. This allows any conformant stream implementation to be added
as a blob.
This is useful in the case where the contents of the blob would be too large to
create from memory (as 'create_blob_fromstring' allows) and avoids having to
write the data to disk (as 'create_blob_fromworkdir' allows). The latter
operation is especially useful when reading data from a network socket, since
it avoids having to first commit all the data to disk.
This is the function which does the work for Repository.merge_commits()
and allows us more direct control over which trees we want to merge,
including trees which do not belong to commits.
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.
As we allow users of the library to use short strings, we must expand
them. This is however only available through a function in C. Expose
that function from the repository to allow python code to get a full id
from a short hex string.
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.
Initializers for the char * fields of the git_repository_init_options
structure must be cdata pointers.
Signed-off-by: Lukas Fleischer <info@cryptocrack.de>
Add a description of the possible flags and turn the "tuple" into a
"list", as it had already happened in code and part of the documentation
in aa5877e0.
The git-branch recipe says: »Note that the next release will probably
allow repo.listall_branches().« Concluding from the README,
Repository.listall_branches() was included in some release prior to
0.20.0, so at least that statement is obsolete.
However, since pygit2.org brings up fairly accurate results for a search
on »list all branches«, I figured that the whole recipe isn't needed
anymore. Therefore delete it.
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.
