Files
libgit2/tests
Edward Thomson e279d645f1 oid: sha1s must now be zero-padded
Now that we have two types of object IDs, with different sizes, we
expect shorter object ID types (in other words, SHA1 object ids) to be
zero-padded at their suffix. This allows us to use faster comparison and
copy routines over the entirety of the structure, instead of trying to
examine the type and then do a comparison of the appropriately sized
structure.

For pure manipulation of object IDs, this produces parity with the
SHA1-only object ID code.

SHA1:
oid::cmp_sha1:  8.065 ms ± 703.9 μs / range: 7.875 ms … 14.88 ms  (201 runs)
oid::cmp_sha256:  skipped
oid::cpy_sha1:  5.340 ms ± 47.26 μs / range: 5.272 ms … 5.617 ms  (548 runs)
oid::cpy_sha256:  skipped
oid::zero_sha1:  5.327 ms ± 49.27 μs / range: 5.271 ms … 5.612 ms  (553 runs)
oid::zero_sha256:  skipped

SHA256 (before this change; testing the `type`):
oid::cmp_sha1:  10.82 ms ± 1.029 ms / range: 10.57 ms … 20.63 ms  (145 runs)
oid::cmp_sha256:  10.63 ms ± 103.9 μs / range: 10.50 ms … 11.48 ms  (279 runs)
oid::cpy_sha1:  26.13 ms ± 63.91 μs / range: 26.07 ms … 26.45 ms  (113 runs)
oid::cpy_sha256:  20.92 ms ± 58.32 μs / range: 20.86 ms … 21.25 ms  (141 runs)
oid::zero_sha1:  13.19 ms ± 129.1 μs / range: 13.11 ms … 13.72 ms  (224 runs)
oid::zero_sha256:  13.12 ms ± 30.06 μs / range: 13.10 ms … 13.30 ms  (225 runs)

SHA256 (with this change):
oid::cmp_sha1:  7.985 ms ± 562.3 μs / range: 7.874 ms … 14.32 ms  (209 runs)
oid::cmp_sha256:  6.609 ms ± 30.77 μs / range: 6.584 ms … 6.870 ms  (443 runs)
oid::cpy_sha1:  5.282 ms ± 21.90 μs / range: 5.266 ms … 5.524 ms  (543 runs)
oid::cpy_sha256:  5.279 ms ± 17.57 μs / range: 5.263 ms … 5.415 ms  (554 runs)
oid::zero_sha1:  5.288 ms ± 22.92 μs / range: 5.268 ms … 5.508 ms  (544 runs)
oid::zero_sha256:  5.286 ms ± 21.29 μs / range: 5.271 ms … 5.527 ms  (542 runs)
2026-05-06 23:03:46 +01:00
..

libgit2 tests

These are the unit and integration tests for the libgit2 projects.

  • headertest
    This is a simple project that ensures that our public headers are compatible with extremely strict compilation options.
  • libgit2
    These tests exercise the core git functionality in libgit2 itself.
  • resources
    These are the resources for the tests, including files and git repositories.
  • util
    These are tests of the common utility library.

Writing tests for libgit2

libgit2 uses the clar test framework, a C testing framework.

The best resources for learning clar are clar itself and the existing tests within libgit2. In general:

  • If you place a .c file into a test directory, it is eligible to contain test cases.

  • The function name for your test is important; test function names begin with test_, followed by the folder path (underscore separated), two underscores as a delimiter, then the test name. For example, a file merge/analysis.c may contain a test uptodate:

    void test_merge_analysis__uptodate(void)
    {
      ...
    }
    
  • You can run an individual test by passing -s to the test runner. Tests are referred to by their function names; for example, the function test_merge_analysis__uptodate is referred to as merge::analysis::uptodate. To run only that function you can use the -s option on the test runner:

    libgit2_tests -smerge::analysis::uptodate
    

Memory leak checking

These are automatically run as part of CI, but if you want to check locally:

Linux

Uses valgrind:

$ cmake -DBUILD_TESTS=ON -DVALGRIND=ON ..
$ cmake --build .
$ valgrind --leak-check=full --show-reachable=yes --num-callers=50 --suppressions=../libgit2_tests.supp \
  ./libgit2_tests

macOS

Uses leaks, which requires XCode installed:

$ MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT="leaks -quiet \$PPID" \
  ./libgit2_tests

Windows

Build with the WIN32_LEAKCHECK option:

$ cmake -DBUILD_TESTS=ON -DWIN32_LEAKCHECK=ON ..
$ cmake --build .
$ ./libgit2_tests