1. 25 Jun, 2021 1 commit
  2. 23 Jun, 2021 1 commit
  3. 17 Jun, 2021 1 commit
  4. 11 Jun, 2021 1 commit
  5. 27 May, 2021 1 commit
  6. 14 Apr, 2021 1 commit
  7. 21 Nov, 2020 1 commit
  8. 25 Oct, 2020 1 commit
  9. 12 Oct, 2020 1 commit
  10. 05 Apr, 2020 1 commit
    • docs: add documentation for our coding style · ffb6a576
      For years, we've repeatedly had confusion about what our actual coding
      style is not only for newcomers, but also across the core contributors.
      This can mostly be attributed to the fact that we do not have any coding
      conventions written down. This is now a thing of the past with the
      introduction of a new document that gives an initial overview of our
      style and most important best practices for both our C codebase as well
      as for CMake.
      
      While the proposed coding style for our C codebase should be rather
      uncontroversial, the coding style for CMake might be. This can be
      attributed to multiple facts. First, the CMake code base doesn't really
      have any uniform coding style and is quite outdated in a lot of places.
      Second, the proposed coding style actually breaks with our existing one:
      we currently use all-uppercase function names and variables, but the
      documented coding style says we use all-lowercase function names but
      all-uppercase variables.
      
      It's common practice in CMake to write variables in all upper-case, and
      in fact all variables made available by CMake are exactly that. As
      variables are case-sensitive in CMake, we cannot and shouldn't break
      with this. In contrast, function calls are case insensitive, and modern
      CMake always uses all-lowercase ones. I argue we should do the same to
      get in line with other codebases and to reduce the likelihood of
      repetitive strain injuries.
      
      So especially for CMake, the proposed coding style says something we
      don't have yet. I'm fine with that, as the document explicitly says that
      it's what we want to have and not what we have right now.
      Patrick Steinhardt committed
  11. 28 Mar, 2020 1 commit
  12. 19 Feb, 2020 1 commit
  13. 15 Feb, 2020 1 commit
  14. 10 Dec, 2019 1 commit
  15. 04 Dec, 2019 2 commits
  16. 13 Sep, 2019 1 commit
  17. 13 Aug, 2019 1 commit
  18. 14 Jun, 2019 1 commit
    • cmake: Modulize our TLS & hash detection · 94fc83b6
      The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
      streamlined. Previously we would have accepted not quite working
      configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
      the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.
      
      The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
      which takes the values "CollisionDetection/Backend/Generic", to better
      match how the "hashing backend" is selected, the default (ON) being
      "CollisionDetection".
      
      Note that, as `SHA1_BACKEND` is still used internally, you might need to
      check what customization you're using it for.
      Etienne Samson committed
  19. 13 Jun, 2019 1 commit
    • http-parser: use our bundled http-parser by default · fb529a01
      Our bundled http-parser includes bugfixes, therefore we should prefer
      our http-parser until such time as we can identify that the system
      http-parser has these bugfixes (using a version check).
      
      Since these bugs are - at present - minor, retain the ability for users
      to force that they want to use the system http-parser anyway.  This does
      change the cmake specification so that people _must_ opt-in to the new
      behavior knowingly.
      Edward Thomson committed
  20. 27 Feb, 2019 2 commits
  21. 07 Feb, 2019 1 commit
  22. 31 Jan, 2019 1 commit
  23. 28 Jan, 2019 1 commit
  24. 25 Jan, 2019 1 commit
  25. 24 Jan, 2019 1 commit
    • index: preserve extension parsing errors · 0bf7e043
      Previously, we would clobber any extension-specific error message with
      an "extension is truncated" message. This makes `read_extension`
      correctly preserve those errors, takes responsibility for truncation
      errors, and adds a new message with the actual extension signature for
      unsupported mandatory extensions.
      Etienne Samson committed
  26. 22 Jan, 2019 1 commit
  27. 17 Jan, 2019 6 commits
  28. 19 Oct, 2018 1 commit
  29. 30 Aug, 2018 1 commit
    • docs: clarify and include licenses of dependencies · 2e0f926e
      While our contribution guide tries to make clear the licenses that apply
      to libgit2, it does not make clear that different licenses apply to our
      bundled dependencies. Make this clear by listing each dependency
      together with the licenses that they are governed by. Furthermore,
      bundle the complete license texts next to the code they apply to.
      Patrick Steinhardt committed
  30. 27 Aug, 2018 1 commit
  31. 20 Aug, 2018 2 commits
  32. 03 Aug, 2018 1 commit
    • cmake: remove USE_SANITIZER and USE_COVERAGE options · 12804c46
      Both the USE_SANITIZER and USE_COVERAGE options are convenience options
      that turn on a set of CFLAGS. Despite our own set of CFLAGS required to
      build libgit2, we have no real business to mess with them, though, as
      they can easily be passed in by the user via specifying the CFLAGS
      environment variable. The reasoning behind not providing them is that as
      soon as we start adding those for some usecases, users might ask for
      other sets of CFLAGS catering to their specific need in another usecase.
      Thus, we do not want to support them here.
      Patrick Steinhardt committed