Otherwise their prototypes don't match their declarations.
Detected by 'sparse', which is obviously good to run
before each commit.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using it in the first place means something's wrong.
This patch replaces it with an internal header which
carries the previously "protected" code instead.
Internal source-files simply include "commit.h" and
they're done. The internal header includes the public
one to make sure we always use the proper prototype.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It doesn't cover all cases, but we can work on those as
we go along. For now, gcc, MSVC++, Intel C/C++, IBM XL C/C++,
Sun Studio C/C++ and Borland C++ Builder are the supported
compilers (although we boldly assume that they all are of
a recent enough version to support thread-local storage).
This is intended to be used in upcoming patches that implement
graceful (but TLS-dependant) error-handling in the library.
As an added bonus, we also bring the online_cpus() function
from git.git to detect the number of usable cpu's.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It's arguably smoother to keep them close to the source,
as that's where one's working when modifying them. More
importantly, though, is the ability to use private headers
in the src/ dir that simply include "git/$samename.h" to
get to the public API at the same time.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git_revp is something I personally can't stop pronouncing
"rev pointer". I'm sure others would suffer the same
problem.
Also, rename the git_revp_ sub-api "gitrp_". This is the
first of many such renames, primarily done to prevent
extreme inflation in the "git_" namespace, which we'd like
to reserve for a higher-level API.
While we're at it, we remove the noise-char "c" from a lot
of functions. Since revision walking is all about commits,
the common case should be that we're dealing with commits.
Exceptions can get a more mnemonic description as needed.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The 's' never really made sense, since it's not a "small"
object at all, but rather a plain object. As such, it should
have a "plain" object name.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We never want to accept a short read or a short write when
transferring data to or from a local file.
Either the entire read (or write) completes or the operation
failed and we will not recover gracefully from it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
These are easily built off the standard C library functions memcpy
and memcmp. By marking these inline we stand a good chance of
the C compiler replacing the entire thing with tight machine code,
because many compilers will actually inline a memcmp or memcpy when
the 3rd argument (the size) is a constant value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This way we can start to write IO code to read and write files in the
Git object database, but provide a hook to inject native Win32 APIs
instead so libgit2 can be ported to run natively on that platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This isn't the best idea I've head. Pierre Habouzit was suggesting
a technique of assigning a unique integer to each commit and then
allocating storage out of auxiliary pools, using the commit's unique
integer to index into any auxiliary pool in constant time. This way
both applications and the library can efficiently attach arbitrary
data onto a commit, such as rewritten parents, or flags, and have
them disconnected from the main object hash table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This way only structures we ask the caller to allocate on their
call stack or which we want to allow them to use members from
are shown in the API docs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most read calls will use the small object format, as the
majority of the content within the database is very small
objects (under 20 KB when inflated).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
