tests/object/lookup.c


Log

Author Commit Date CI Message
Edward Thomson 168fe39b 2018-11-28T14:26:57 object_type: use new enumeration names Use the new object_type enumeration names within the codebase.
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Edward Thomson 1dc89aab 2017-05-01T21:34:21 object validation: free some memleaks
Patrick Steinhardt 35079f50 2017-04-21T07:31:56 odb: add option to turn off hash verification Verifying hashsums of objects we are reading from the ODB may be costly as we have to perform an additional hashsum calculation on the object. Especially when reading large objects, the penalty can be as high as 35%, as can be seen when executing the equivalent of `git cat-file` with and without verification enabled. To mitigate for this, we add a global option for libgit2 which enables the developer to turn off the verification, e.g. when he can be reasonably sure that the objects on disk won't be corrupted.
Patrick Steinhardt 28a0741f 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.
Patrick Steinhardt d59dabe5 2017-04-10T09:00:51 tests: object: test looking up corrupted objects We currently have no tests which check whether we fail reading corrupted objects. Add one which modifies contents of an object stored on disk and then tries to read the object.
Patrick Steinhardt 86c03552 2017-04-10T09:27:04 tests: object: create sandbox The object::lookup tests do use the "testrepo.git" repository in a read-only way, so we do not set up the repository as a sandbox but simply open it. But in a future commit, we will want to test looking up objects which are corrupted in some way, which requires us to modify the on-disk data. Doing this in a repository without creating the sandbox will modify contents of our libgit2 repository, though. Create the repository in a sandbox to avoid this.
Ben Straub 17820381 2013-11-14T14:05:52 Rename tests-clar to tests