1. 20 Jun, 2022 1 commit
  2. 23 Feb, 2022 2 commits
  3. 18 Jan, 2022 1 commit
  4. 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
  5. 09 Aug, 2021 2 commits
  6. 26 Jul, 2021 1 commit
  7. 14 Apr, 2021 1 commit
    • utf8: refactor utf8 functions · 1d95b59b
      Move the utf8 functions into a proper namespace `git_utf8` instead of
      being in the namespaceless `git__` function group.  Update them to
      have out-params first and use `char *` instead of `uint8_t *` to match
      our API treating strings as `char *` (even if they truly contain `uchar`s
      inside).
      Edward Thomson committed
  8. 08 Dec, 2020 1 commit
  9. 06 Dec, 2020 1 commit
  10. 11 May, 2020 2 commits
    • assert: optionally fall-back to assert(3) · a95096ba
      Fall back to the system assert(3) in debug builds, which may aide
      in debugging.
      
      "Safe" assertions can be enabled in debug builds by setting
      GIT_ASSERT_HARD=0.  Similarly, hard assertions can be enabled in
      release builds by setting GIT_ASSERT_HARD to nonzero.
      Edward Thomson committed
    • Introduce GIT_ASSERT macros · abe2efe1
      Provide macros to replace usages of `assert`.  A true `assert` is
      punishing as a library.  Instead we should do our best to not crash.
      
      GIT_ASSERT_ARG(x) will now assert that the given argument complies to
      some format and sets an error message and returns `-1` if it does not.
      
      GIT_ASSERT(x) is for internal usage, and available as an internal
      consistency check.  It will set an error message and return `-1` in the
      event of failure.
      Edward Thomson committed
  11. 21 Sep, 2019 1 commit
  12. 19 May, 2019 2 commits
  13. 14 Feb, 2019 1 commit
    • deprecation: ensure we GIT_EXTERN deprecated funcs · 24ac9e0c
      Although the error functions were deprecated, we did not properly mark
      them as deprecated.  We need to include the `deprecated.h` file in order
      to ensure that the functions get their export attributes.
      
      Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or
      those functions will also not get their export attributes.  Define that
      only on the tests and examples.
      Edward Thomson committed
  14. 22 Jan, 2019 1 commit
  15. 13 Jul, 2018 1 commit
    • treewide: avoid use of `inline` attribute · f347a441
      ISO C90 does not specify the `inline` attribute, and as such we cannot
      use it in our code. While we already use `__inline` when building in
      Microsoft Visual Studio, we should also be using the `__inline__`
      attribute from GCC/Clang. Otherwise, if we're using neither MSVC nor
      GCC/Clang, we should simply avoid using `inline` at all and just define
      functions as static.
      
      This commit adjusts our own `GIT_INLINE` macro as well as the inline
      macros specified by khash and xdiff. This allows us to enable strict C90
      mode in a later commit.
      Patrick Steinhardt committed
  16. 01 Feb, 2018 1 commit
  17. 21 Jan, 2018 1 commit
  18. 12 Sep, 2017 1 commit
    • features.h: allow building without CMake-generated feature header · 26f531d3
      In commit a390a846 (cmake: move defines into "features.h" header,
      2017-07-01), we have introduced a new "features.h" header. This file is
      being generated by the CMake build system based on how the libgit2 build
      has been configured, replacing the preexisting method of simply setting
      the defines inside of the CMake build system. This was done to help
      splitting up the build instructions into multiple separate
      subdirectories.
      
      An overlooked shortcoming of this approach is that some projects making
      use of libgit2 build the library with custom build systems, without
      making use of CMake. For those users, the introduction of the
      "features.h" file makes their life harder as they would have to also
      generate this file.
      
      Fix this issue by guarding all inclusions of the generated header file
      by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems
      can skip the feature header and simply define all used features by
      specifying `-D` flags for the compiler again.
      Patrick Steinhardt committed
  19. 16 Aug, 2017 1 commit
    • cmake: move defines into "features.h" header · a390a846
      In a future commit, we will split out the build instructions for our
      library directory and move them into a subdirectory. One of the benefits
      is fixing scoping issues, where e.g. defines do not leak to build
      targets where they do not belong to. But unfortunately, this does also
      pose the problem of how to propagate some defines which are required by
      both the library and the test suite.
      
      One way would be to create another variable keeping track of all added
      defines and declare it inside of the parent scope. While this is the
      most obvious and simplest way of going ahead, it is kind of unfortunate.
      The main reason to not use this is that these defines become implicit
      dependencies between the build targets. By simply observing a define
      inside of the CMakeLists.txt file, one cannot reason whether this define
      is only required by the current target or whether it is required by
      different targets, as well.
      
      Another approach would be to use an internal header file keeping track
      of all defines shared between targets. While configuring the library, we
      will set various variables and let CMake configure the file, adding or
      removing defines based on what has been configured. Like this, one can
      easily keep track of the current environment by simply inspecting the
      header file. Furthermore, these dependencies are becoming clear inside
      the CMakeLists.txt, as instead of simply adding a define, we now call
      e.g. `SET(GIT_THREADSAFE 1)`.
      
      Having this header file though requires us to make sure it is always
      included before any "#ifdef"-preprocessor checks are executed. As we
      have already refactored code to always include the "common.h" header
      file before any statement inside of a file, this becomes easy: just make
      sure "common.h" includes the new "features.h" header file first.
      Patrick Steinhardt committed
  20. 30 Jun, 2017 1 commit
    • win32: fix circular include deps with w32_crtdbg · 459fb8fe
      The current order of declarations and includes between "common.h" and
      "w32_crtdbg_stacktrace.h" is rather complicated. Both header files make
      use of things defined in the other one and are thus circularly dependent
      on each other. This makes it currently impossible to compile the
      "w32_crtdbg_stacktrace.c" file when including "common.h" inside of
      "w32_crtdbg_stacktrace.h".
      
      We can disentangle the mess by moving declaration of the inline crtdbg
      functions into the "w32_crtdbg_stacktrace.h" file and adding additional
      includes inside of it, such that all required functions are available to
      it. This allows us to break the dependency cycle.
      Patrick Steinhardt committed
  21. 29 Dec, 2016 1 commit
  22. 14 Nov, 2016 1 commit
  23. 20 Jun, 2016 1 commit
    • win32: rename pthread.{c,h} to thread.{c,h} · 8aaa9fb6
      The old pthread-file did re-implement the pthreads API with exact symbol
      matching. As the thread-abstraction has now been split up between Unix- and
      Windows-specific files within the `git_` namespace to avoid symbol-clashes
      between libgit2 and pthreads, the rewritten wrappers have nothing to do with
      pthreads anymore.
      
      Rename the Windows-specific pthread-files to honor this change.
      Patrick Steinhardt committed
  24. 23 Feb, 2016 1 commit
  25. 09 Feb, 2016 1 commit
  26. 05 Oct, 2015 1 commit
  27. 19 Sep, 2015 1 commit
  28. 03 Aug, 2015 1 commit
  29. 29 Jun, 2015 1 commit
  30. 11 May, 2015 1 commit
  31. 02 Mar, 2015 1 commit
  32. 13 Feb, 2015 5 commits