| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Teach the packfile machinery to cope with SHA256.
|
|
|
|
|
| |
The experimental function signature is only available when
`GIT_EXPERIMENTAL_SHA256` is enabled.
|
|
|
|
|
|
|
|
|
|
| |
libgit2 can be built with optional, experimental sha256 support. This
allows consumers to begin testing and providing feedback for our sha256
support while we continue to develop it, and allows us to make API
breaking changes while we iterate on a final sha256 implementation.
The results will be `git2-experimental.dll` and installed as
`git2-experimental.h` to avoid confusion with a production libgit2.
|
|
|
|
| |
Teach the loose object database how to cope with SHA256 objects.
|
|
|
|
| |
Move the arguments to `git_odb_loose` into an options structure.
|
|
|
|
|
| |
Allow the object database to take an oid type that it supports. This
oid type will be used to validate the objects that the backends provide.
|
|
|
|
|
| |
Users will need to be able to specify the object id type for the given
object database; add a new `git_odb_options` with that option.
|
|
|
|
|
| |
The git_odb_hash helper functions should not assume SHA1, and instead
should be given the oid type that they're producing.
|
|
|
|
|
| |
`git_oid`s now have a type, and we require the oid type when creating
the object id from creation functions.
|
|
|
|
|
| |
Callers should not assume the layout of the oid structure; provide them
a macro that defines the null / zero sha1 object id.
|
|
|
|
|
| |
In preparation for SHA256 support, `GIT_OID_RAWSZ` and `GIT_OID_HEXSZ`
need to indicate that they're the size of _SHA1_ OIDs.
|
|
|
|
|
|
|
|
|
|
| |
Instead of simply including the utility files directly, make them a
cmake object library for easy reusability between other projects within
libgit2.
Now the top-level `src` is responsible for platform selection, while the
next-level `libgit2` and `util` configurations are responsible for
identifying what objects they include.
|
|
|