Name |
Last commit
|
Last update |
---|---|---|
deps | ||
examples | ||
include | ||
src | ||
tests | ||
tests-clar | ||
.HEADER | ||
.gitattributes | ||
.gitignore | ||
AUTHORS | ||
CMakeLists.txt | ||
CONVENTIONS | ||
COPYING | ||
Makefile.embed | ||
README.md | ||
api.docurium | ||
git.git-authors | ||
libgit2.pc.in |
This makes so much sense that I can't believe it hasn't been done before. Kill the old `git_fbuffer` and read files straight into `git_buf` objects. Also: In order to fully support 4GB files in 32-bit systems, the `git_buf` implementation has been changed from using `ssize_t` for storage and storing negative values on allocation failure, to using `size_t` and changing the buffer pointer to a magical pointer on allocation failure. Hopefully this won't break anything.
Name |
Last commit
|
Last update |
---|---|---|
deps | Loading commit data... | |
examples | Loading commit data... | |
include | Loading commit data... | |
src | Loading commit data... | |
tests | Loading commit data... | |
tests-clar | Loading commit data... | |
.HEADER | Loading commit data... | |
.gitattributes | Loading commit data... | |
.gitignore | Loading commit data... | |
AUTHORS | Loading commit data... | |
CMakeLists.txt | Loading commit data... | |
CONVENTIONS | Loading commit data... | |
COPYING | Loading commit data... | |
Makefile.embed | Loading commit data... | |
README.md | Loading commit data... | |
api.docurium | Loading commit data... | |
git.git-authors | Loading commit data... | |
libgit2.pc.in | Loading commit data... |