1. 13 May, 2023 5 commits
  2. 12 May, 2023 1 commit
  3. 11 May, 2023 1 commit
  4. 09 May, 2023 1 commit
  5. 08 May, 2023 2 commits
    • util: detect all possible qsort_r and qsort_s variants · d873966f
      As reported in https://bugs.freebsd.org/271234, recent versions of
      FreeBSD have adjusted the prototype for qsort_r() to match the POSIX
      interface. This causes libgit2's CMake configuration check to fail to
      detect qsort_r(), making it fall back to qsort_s(), which in libgit2
      also has an incompatible interface. With recent versions of clang this
      results in a "incompatible function pointer types" compile error.
      
      Summarizing, there are four variations of 'qsort-with-context':
      * old style BSD qsort_r(), used in FreeBSD 13 and earlier, where the
        comparison function has the context parameter first
      * GNU or POSIX qsort_r(), also used in FreeBSD 14 and later, where the
        comparison function has the context parameter last
      * C11 qsort_s(), where the comparison function has the context parameter
        last
      * Microsoft qsort_s(), where the comparison function has the context
        parameter first
      
      Add explicit detections for all these variants, so they get detected as
      (in the same order as above):
      
      * `GIT_QSORT_R_BSD`
      * `GIT_QSORT_R_GNU`
      * `GIT_QSORT_S_C11`
      * `GIT_QSORT_S_MSC`
      
      An additional complication is that on FreeBSD 14 and later, <stdlib.h>
      uses the C11 _Generic() macro mechanism to automatically select the
      correct qsort_r() prototype, depending on the caller's comparison
      function argument. This breaks CMake's check_prototype_definition()
      functionality, since it tries to redefine the function, and _Generic
      macro is expanded inline causing a compile error.
      
      Work around that problem by putting the function names in parentheses,
      to prevent the preprocessor from using a macro to replace the function
      name.
      
      Also, in `git__qsort_r()`, change the `#if` order so the variants that
      do not have to use glue are preferred.
      Dimitry Andric committed
    • futils: use SHA256 for checksums always · 6a02b459
      Use SHA256 for file checksums. SHA1 makes no sense as a default in 2023.
      
      Given that we're just looking at a file checksum to see if it's changed,
      this does not need to take repository's OID type into account or
      otherwise be configurable.
      Edward Thomson committed
  6. 08 Apr, 2023 1 commit
  7. 21 Mar, 2023 2 commits
  8. 10 Mar, 2023 1 commit
  9. 24 Feb, 2023 1 commit
  10. 18 Feb, 2023 1 commit
  11. 12 Feb, 2023 1 commit
  12. 10 Feb, 2023 1 commit
  13. 09 Feb, 2023 1 commit
  14. 02 Feb, 2023 1 commit
  15. 24 Jan, 2023 2 commits
  16. 23 Nov, 2022 1 commit
  17. 22 Sep, 2022 2 commits
  18. 19 Sep, 2022 1 commit
  19. 14 Aug, 2022 1 commit
  20. 09 Aug, 2022 1 commit
  21. 08 Aug, 2022 1 commit
  22. 12 Jul, 2022 1 commit
  23. 07 Jul, 2022 3 commits
  24. 20 Jun, 2022 2 commits
  25. 17 Jun, 2022 2 commits
  26. 13 Jun, 2022 1 commit
  27. 12 Apr, 2022 1 commit
  28. 11 Apr, 2022 1 commit