1. 12 Feb, 2022 1 commit
    • diff: indicate when the file size is "valid" · 359240b6
      When we know the file size (because we're producing it from a working
      directory iterator, or an index with an up-to-date cache) then set a
      flag indicating as such.  This removes the ambiguity about a 0 file
      size, which could indicate that a file exists and is 0 bytes, or that we
      haven't read it yet.
      Edward Thomson committed
  2. 07 Feb, 2022 1 commit
  3. 09 Nov, 2021 1 commit
  4. 08 Nov, 2021 1 commit
    • Support checking for object existence without refresh · 81662d43
      Looking up a non-existent object currently always invokes
      `git_odb_refresh`. If looking up a large batch of objects, many of which
      may legitimately not exist, this will repeatedly refresh the ODB to no
      avail.
      
      Add a `git_odb_exists_ext` that accepts flags controlling the ODB
      lookup, and add a flag to suppress the refresh. This allows the user to
      control if and when they refresh (for instance, refreshing once before
      starting the batch).
      Josh Triplett committed
  5. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      libgit2 has two distinct requirements that were previously solved by
      `git_buf`.  We require:
      
      1. A general purpose string class that provides a number of utility APIs
         for manipulating data (eg, concatenating, truncating, etc).
      2. A structure that we can use to return strings to callers that they
         can take ownership of.
      
      By using a single class (`git_buf`) for both of these purposes, we have
      confused the API to the point that refactorings are difficult and
      reasoning about correctness is also difficult.
      
      Move the utility class `git_buf` to be called `git_str`: this represents
      its general purpose, as an internal string buffer class.  The name also
      is an homage to Junio Hamano ("gitstr").
      
      The public API remains `git_buf`, and has a much smaller footprint.  It
      is generally only used as an "out" param with strict requirements that
      follow the documentation.  (Exceptions exist for some legacy APIs to
      avoid breaking callers unnecessarily.)
      
      Utility functions exist to convert a user-specified `git_buf` to a
      `git_str` so that we can call internal functions, then converting it
      back again.
      Edward Thomson committed
  6. 02 Oct, 2021 1 commit
  7. 01 Oct, 2021 1 commit
  8. 27 Aug, 2021 1 commit
  9. 09 Aug, 2021 1 commit
  10. 30 Jul, 2021 2 commits
  11. 30 May, 2021 1 commit
  12. 06 May, 2021 1 commit
    • filter: internal git_buf filter handling function · 31d9c24b
      Introduce `git_filter_list__convert_buf` which behaves like the old
      implementation of `git_filter_list__apply_data`, where it might move the
      input data buffer over into the output data buffer space for efficiency.
      
      This new implementation will do so in a more predictible way, always
      freeing the given input buffer (either moving it to the output buffer or
      filtering it into the output buffer first).
      
      Convert internal users to it.
      Edward Thomson committed
  13. 10 Mar, 2021 2 commits
    • commit-graph: Create `git_commit_graph` as an abstraction for the file · 25b75cd9
      This change does a medium-size refactor of the git_commit_graph_file and
      the interaction with the ODB. Now instead of the ODB owning a direct
      reference to the git_commit_graph_file, there will be an intermediate
      git_commit_graph. The main advantage of that is that now end users can
      explicitly set a git_commit_graph that is eagerly checked for errors,
      while still being able to lazily use the commit-graph in a regular ODB,
      if the file is present.
      lhchavez committed
    • commit-graph: Use the commit-graph in revwalks · 248606eb
      This change makes revwalks a bit faster by using the `commit-graph` file
      (if present). This is thanks to the `commit-graph` allow much faster
      parsing of the commit information by requiring near-zero I/O (aside from
      reading a few dozen bytes off of a `mmap(2)`-ed file) for each commit,
      instead of having to read the ODB, inflate the commit, and parse it.
      
      This is done by modifying `git_commit_list_parse()` and letting it use
      the ODB-owned commit-graph file.
      
      Part of: #5757
      lhchavez committed
  14. 28 Nov, 2020 1 commit
  15. 27 Nov, 2020 1 commit
  16. 08 Oct, 2020 1 commit
    • Improve the support of atomics · cc1d7f5c
      This change:
      
      * Starts using GCC's and clang's `__atomic_*` intrinsics instead of the
        `__sync_*` ones, since the former supercede the latter (and can be
        safely replaced by their equivalent `__atomic_*` version with the
        sequentially consistent model).
      * Makes `git_atomic64`'s value `volatile`. Otherwise, this will make
        ThreadSanitizer complain.
      * Adds ways to load the values from atomics. As it turns out,
        unsynchronized read are okay only in some architectures, but if we
        want to be correct (and make ThreadSanitizer happy), those loads
        should also be performed with the atomic builtins.
      * Fixes two ThreadSanitizer warnings, as a proof-of-concept that this
        works:
        - Avoid directly accessing `git_refcount`'s `owner` directly, and
          instead makes all callers go through the `GIT_REFCOUNT_*()` macros,
          which also use the atomic utilities.
        - Makes `pool_system_page_size()` race-free.
      
      Part of: #5592
      lhchavez committed
  17. 30 Jun, 2020 1 commit
  18. 09 Jun, 2020 1 commit
    • tree-wide: do not compile deprecated functions with hard deprecation · c6184f0c
      When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor
      definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h"
      header to be empty. As a result, no function declarations are made
      available to callers, but the implementations are still available to
      link against. This has the problem that function declarations also
      aren't visible to the implementations, meaning that the symbol's
      visibility will not be set up correctly. As a result, the resulting
      library may not expose those deprecated symbols at all on some platforms
      and thus cause linking errors.
      
      Fix the issue by conditionally compiling deprecated functions, only.
      While it becomes impossible to link against such a library in case one
      uses deprecated functions, distributors of libgit2 aren't expected to
      pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually
      define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real"
      hard deprecation still makes sense in the context of CI to test we don't
      use deprecated symbols ourselves and in case a dependant uses libgit2 in
      a vendored way and knows it won't ever use any of the deprecated symbols
      anyway.
      Patrick Steinhardt committed
  19. 22 Nov, 2019 2 commits
  20. 20 Jul, 2019 1 commit
  21. 18 Jul, 2019 1 commit
  22. 26 Jun, 2019 1 commit
  23. 15 Jun, 2019 1 commit
  24. 23 Feb, 2019 2 commits
    • odb: provide a free function for custom backends · 459ac856
      Custom backends can allocate memory when reading objects and providing
      them to libgit2.  However, if an error occurs in the custom backend
      after the memory has been allocated for the custom object but before
      it's returned to libgit2, the custom backend has no way to free that
      memory and it must be leaked.
      
      Provide a free function that corresponds to the alloc function so that
      custom backends have an opportunity to free memory before they return an
      error.
      Edward Thomson committed
    • odb: rename git_odb_backend_malloc for consistency · 790aae77
      The `git_odb_backend_malloc` name is a system function that is provided
      for custom ODB backends and allows them to allocate memory for an ODB
      object in the read callback.  This is important so that libgit2 can
      later free the memory used by an ODB object that was read from the
      custom backend.
      
      However, the name _suggests_ that it actually allocates a
      `git_odb_backend`.  It does not; rename it to make it clear that it
      actually allocates backend _data_.
      Edward Thomson committed
  25. 22 Feb, 2019 1 commit
  26. 21 Feb, 2019 1 commit
    • cache: fix misnaming of `git_cache_free` · bbdcd450
      Functions that free a structure's contents but not the structure
      itself shall be named `dispose` in the libgit2 project, but the
      function `git_cache_free` does not follow this naming pattern.
      
      Fix this by renaming it to `git_cache_dispose` and adjusting all
      callers to make use of the new name.
      Patrick Steinhardt committed
  27. 20 Feb, 2019 1 commit
  28. 17 Feb, 2019 1 commit
  29. 25 Jan, 2019 1 commit
  30. 22 Jan, 2019 1 commit
  31. 20 Jan, 2019 1 commit
  32. 17 Jan, 2019 1 commit
  33. 06 Jan, 2019 1 commit
    • Fix a bunch of warnings · 7b453e7e
      This change fixes a bunch of warnings that were discovered by compiling
      with `clang -target=i386-pc-linux-gnu`. It turned out that the
      intrinsics were not necessarily being used in all platforms! Especially
      in GCC, since it does not support __has_builtin.
      
      Some more warnings were gleaned from the Windows build, but I stopped
      when I saw that some third-party dependencies (e.g. zlib) have warnings
      of their own, so we might never be able to enable -Werror there.
      lhchavez committed
  34. 01 Dec, 2018 1 commit
  35. 06 Aug, 2018 1 commit
    • odb: fix use of wrong printf formatters · 0fcd0563
      The `git_odb_stream` members `declared_size` and `received_bytes` are
      both of the type `git_off_t`, which we usually defined to be a 64 bit
      signed integer. Thus, passing these members to "PRIdZ" formatters is not
      correct, as they are not guaranteed to accept big enough numbers.
      Instead, use the "PRId64" formatter, which is able to represent 64 bit
      signed integers.
      Patrick Steinhardt committed
  36. 10 Jun, 2018 1 commit