• Show log

    Commit

  • Hash : 28a0741f
    Author : Patrick Steinhardt
    Date : 2017-04-10T09:30:08

    odb: verify object hashes
    
    The upstream git.git project verifies objects when looking them up from
    disk. This avoids scenarios where objects have somehow become corrupt on
    disk, e.g. due to hardware failures or bit flips. While our mantra is
    usually to follow upstream behavior, we do not do so in this case, as we
    never check hashes of objects we have just read from disk.
    
    To fix this, we create a new error class `GIT_EMISMATCH` which denotes
    that we have looked up an object with a hashsum mismatch. `odb_read_1`
    will then, after having read the object from its backend, hash the
    object and compare the resulting hash to the expected hash. If hashes do
    not match, it will return an error.
    
    This obviously introduces another computation of checksums and could
    potentially impact performance. Note though that we usually perform I/O
    operations directly before doing this computation, and as such the
    actual overhead should be drowned out by I/O. Running our test suite
    seems to confirm this guess. On a Linux system with best-of-five
    timings, we had 21.592s with the check enabled and 21.590s with the
    ckeck disabled. Note though that our test suite mostly contains very
    small blobs only. It is expected that repositories with bigger blobs may
    notice an increased hit by this check.
    
    In addition to a new test, we also had to change the
    odb::backend::nonrefreshing test suite, which now triggers a hashsum
    mismatch when looking up the commit "deadbeef...". This is expected, as
    the fake backend allocated inside of the test will return an empty
    object for the OID "deadbeef...", which will obviously not hash back to
    "deadbeef..." again. We can simply adjust the hash to equal the hash of
    the empty object here to fix this test.
    

  • README.md

  • Writing Clar tests for libgit2

    For information on the Clar testing framework and a detailed introduction please visit:

    https://github.com/vmg/clar

    • Write your modules and tests. Use good, meaningful names.

    • Make sure you actually build the tests by setting:

        cmake -DBUILD_CLAR=ON build/
    • Test:

        ./build/libgit2_clar
    • Make sure everything is fine.

    • Send your pull request. That’s it.