1. 29 Jul, 2022 2 commits
  2. 28 Jul, 2022 2 commits
  3. 27 Jul, 2022 1 commit
  4. 26 Jul, 2022 1 commit
  5. 14 Jul, 2022 1 commit
  6. 12 Jul, 2022 2 commits
  7. 07 Jul, 2022 2 commits
  8. 20 Jun, 2022 2 commits
  9. 15 Jun, 2022 1 commit
  10. 14 Jun, 2022 1 commit
  11. 12 Apr, 2022 4 commits
  12. 16 Mar, 2022 1 commit
    • Fix a string parsing bug when validating extensions from the configuration · ecc722c3
      As builtin extensions are evaluated in the latter half of `check_valid_extension`, a string `cfg` is concatenated with the static string 'extension.' and the value from `builtin_extension`, before being compared with the configured value. This string is not being cleared while iterating through the names of the extensions. Because there is currently only one extension ('noop'), the bug was never noticible.
      
      This patch corrects the behavior by clearing the string on each iteration, as is done in the first block.
      Wilhelm Bierbaum committed
  13. 23 Feb, 2022 1 commit
  14. 05 Jan, 2022 1 commit
  15. 22 Nov, 2021 1 commit
  16. 12 Nov, 2021 1 commit
  17. 09 Nov, 2021 3 commits
  18. 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
  19. 25 Sep, 2021 1 commit
    • repository: improve `hashfile` for absolute paths · 0f4256b8
      When `git_repository_hashfile` is handed an absolute path, it determines
      whether the path is within the repository's working directory or not.
      This is necessary when there is no `as_path` specified.
      
      If the path is within the working directory, then the given path should
      be used for attribute lookups (it is the effective `as_path`).  If it is
      not within the working directory, then it is _not_ eligible.
      
      Importantly, now we will _never_ pass an absolute path down to attribute
      lookup functions.
      Edward Thomson committed
  20. 09 Sep, 2021 1 commit
  21. 04 Sep, 2021 1 commit
    • common: support custom repository extensions · a24e656a
      Allow users to specify additional repository extensions that they want
      to support.  For example, callers can specify that they support
      `preciousObjects` and then may open repositories that support
      `extensions.preciousObjects`.
      
      Similarly, callers may opt out of supporting extensions that the library
      itself supports.
      Edward Thomson committed
  22. 26 Aug, 2021 1 commit
    • Homogenize semantics for atomic-related functions · 74708a81
      There were some subtle semantic differences between the various
      implementations of atomic functions. Now they behave the same, have
      tests and are better documented to avoid this from happening again in
      the future.
      
      Of note:
      
      * The semantics chosen for `git_atomic_compare_and_swap` match
        `InterlockedCompareExchangePointer`/`__sync_cal_compare_and_swap` now.
      * The semantics chosen for `git_atomic_add` match
        `InterlockedAdd`/`__atomic_add_fetch`.
      * `git_atomic_swap` and `git_atomic_load` still have a bit of semantic
        difference with the gcc builtins / msvc interlocked operations, since
        they require an l-value (not a pointer). If desired, this can be
        homogenized.
      lhchavez committed
  23. 11 Jul, 2021 1 commit
    • repo: fix worktree iteration when repo has no common directory · e71505b3
      When applying an operation to a repository created without a common directory,
      which is known to occur in scenarios where custom odb/refdb backends are used,
      git_repository_foreach_worktree currently asserts while attempting to open the
      repository located in the common directory.
      
      Fix this issue by applying operation to repository supplied when there are no
      linked worktrees to iterate (implied by common directory being empty).
      Kevin Saul committed
  24. 28 Apr, 2021 4 commits
  25. 11 Apr, 2021 2 commits
  26. 01 Apr, 2021 1 commit