1. 01 Jun, 2018 3 commits
  2. 12 Mar, 2018 1 commit
  3. 10 Mar, 2018 2 commits
  4. 08 Mar, 2018 1 commit
  5. 07 Mar, 2018 1 commit
  6. 13 Jun, 2017 2 commits
  7. 12 Jun, 2017 1 commit
  8. 11 Jun, 2017 1 commit
  9. 08 Jun, 2017 1 commit
    • settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` · 6c23704d
      Initially, the setting has been solely used to enable the use of
      `fsync()` when creating objects. Since then, the use has been extended
      to also cover references and index files. As the option is not yet part
      of any release, we can still correct this by renaming the option to
      something more sensible, indicating not only correlation to objects.
      
      This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
      move the variable from the object to repository source code.
      Patrick Steinhardt committed
  10. 04 Jun, 2017 1 commit
  11. 05 May, 2017 2 commits
    • worktree: switch over worktree pruning to an opts structure · 883eeb5f
      The current signature of `git_worktree_prune` accepts a flags field to
      alter its behavior. This is not as flexible as we'd like it to be when
      we want to enable passing additional options in the future. As the
      function has not been part of any release yet, we are still free to
      alter its current signature. This commit does so by using our usual
      pattern of an options structure, which is easily extendable without
      breaking the API.
      Patrick Steinhardt committed
    • worktree: support creating locked worktrees · 8264a30f
      When creating a new worktree, we do have a potential race with us
      creating the worktree and another process trying to delete the same
      worktree as it is being created. As such, the upstream git project has
      introduced a flag `git worktree add --locked`, which will cause the
      newly created worktree to be locked immediately after its creation. This
      mitigates the race condition.
      
      We want to be able to mirror the same behavior. As such, a new flag
      `locked` is added to the options structure of `git_worktree_add` which
      allows the user to enable this behavior.
      Patrick Steinhardt committed
  12. 02 May, 2017 1 commit
    • worktree: introduce git_worktree_add options · a7aa73a5
      The `git_worktree_add` function currently accepts only a path and name
      for the new work tree. As we may want to expand these parameters in
      future versions without adding additional parameters to the function for
      every option, this commit introduces our typical pattern of an options
      struct. Right now, this structure is still empty, which will change with
      the next commit.
      Patrick Steinhardt committed
  13. 01 May, 2017 1 commit
  14. 28 Apr, 2017 2 commits
    • odb: add option to turn off hash verification · 35079f50
      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 committed
    • odb: verify object hashes · 28a0741f
      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 committed
  15. 21 Apr, 2017 1 commit
  16. 17 Apr, 2017 1 commit
  17. 03 Apr, 2017 2 commits
  18. 01 Apr, 2017 1 commit
  19. 21 Mar, 2017 1 commit
  20. 20 Mar, 2017 1 commit
  21. 17 Mar, 2017 1 commit
    • worktree: implement `git_worktree_open_from_repository` · 3017ba94
      While we already provide functionality to look up a worktree from a
      repository, we cannot do so the other way round. That is given a
      repository, we want to look up its worktree if it actually exists.
      Getting the worktree of a repository is useful when we want to get
      certain meta information like the parent's location, getting the locked
      status, etc.
      Patrick Steinhardt committed
  22. 15 Mar, 2017 1 commit
  23. 03 Mar, 2017 1 commit
  24. 28 Feb, 2017 3 commits
  25. 16 Feb, 2017 1 commit
  26. 13 Feb, 2017 6 commits