1. 12 Feb, 2022 3 commits
  2. 28 Jan, 2022 1 commit
    • index: use a byte array for checksum · 11ef76a9
      The index's checksum is not an object ID, so we should not use the
      `git_oid` type.  Use a byte array for checksum calculation and storage.
      
      Deprecate the `git_index_checksum` function without a replacement.  This
      is an abstraction that callers should not care about (and indeed do not
      seem to be using).
      
      Remove the unused `git_index__changed_relative_to` function.
      Edward Thomson committed
  3. 05 Jan, 2022 1 commit
  4. 10 Dec, 2021 1 commit
  5. 11 Nov, 2021 1 commit
  6. 09 Nov, 2021 1 commit
  7. 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
  8. 18 Sep, 2021 2 commits
  9. 18 May, 2021 1 commit
  10. 13 May, 2021 1 commit
  11. 11 May, 2021 1 commit
  12. 16 Sep, 2020 1 commit
  13. 29 Aug, 2020 1 commit
  14. 05 Jun, 2020 2 commits
  15. 23 May, 2020 1 commit
  16. 18 Apr, 2020 1 commit
  17. 07 Feb, 2020 2 commits
    • tests: diff: add test to verify behaviour with empty dir ordering · 17670ef2
      It was reported that, given a file "abc.txt", a diff will be shown if an
      empty directory "abb/" is created, but not if "abd/" is created. Add a
      test to verify that we do the right thing here and do not depend on any
      ordering.
      Patrick Steinhardt committed
    • tests: diff: verify that we are able to diff with empty subtrees · b0691db3
      While it is not allowed for a tree to have an empty tree as child (e.g.
      an empty directory), libgit2's tree builder makes it easy to create such
      trees. As a result, some applications may inadvertently end up with such
      an invalid tree, and we should try our best and handle them.
      
      One such case is when diffing two trees, where one of both trees has
      such an empty subtree. It was reported that this will cause our diff
      code to fail. While I wasn't able to reproduce this error, let's still
      add a test that verifies we continue to handle them correctly.
      Patrick Steinhardt committed
  18. 28 Nov, 2019 1 commit
  19. 16 Oct, 2019 1 commit
  20. 28 Sep, 2019 1 commit
  21. 20 Jul, 2019 1 commit
  22. 18 Jul, 2019 1 commit
  23. 15 Jun, 2019 1 commit
  24. 14 Jun, 2019 1 commit
    • Rename opt init functions to `options_init` · 0b5ba0d7
      In libgit2 nomenclature, when we need to verb a direct object, we name
      a function `git_directobject_verb`.  Thus, if we need to init an options
      structure named `git_foo_options`, then the name of the function that
      does that should be `git_foo_options_init`.
      
      The previous names of `git_foo_init_options` is close - it _sounds_ as
      if it's initializing the options of a `foo`, but in fact
      `git_foo_options` is its own noun that should be respected.
      
      Deprecate the old names; they'll now call directly to the new ones.
      Edward Thomson committed
  25. 06 Apr, 2019 1 commit
  26. 29 Mar, 2019 1 commit
  27. 22 Jan, 2019 1 commit
  28. 01 Dec, 2018 2 commits
  29. 04 Oct, 2018 2 commits
    • diff_stats: use git's formatting of renames with common directories · e5090ee3
      In cases where a file gets renamed such that the directories containing
      it previous and after the rename have a common prefix, then git will
      avoid printing this prefix twice and instead format the rename as
      "prefix/{old => new}". We currently didn't do anything like that, but
      simply printed "prefix/old -> prefix/new".
      
      Adjust our behaviour to instead match upstream. Adjust the test for this
      behaviour to expect the new format.
      Patrick Steinhardt committed
    • tests: verify diff stats with renames in subdirectory · 3148efd2
      Until now, we didn't have any tests that verified that our format for
      renames in subdirectories is correct. While our current behaviour is no
      different than for renames that do not happen with a common prefix
      shared between old and new file name, we intend to change the format to
      instead match the format that upstream git uses.
      
      Add a test case for this to document our current behaviour and to show
      how the next commit will change that format.
      Patrick Steinhardt committed
  30. 06 Jul, 2018 1 commit
  31. 29 Jun, 2018 1 commit
    • delta: fix sign-extension of big left-shift · 7db25870
      Our delta code was originally adapted from JGit, which itself adapted it
      from git itself. Due to this heritage, we inherited a bug from git.git
      in how we compute the delta offset, which was fixed upstream in
      48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
      explained by Linus:
      
          Shifting 'unsigned char' or 'unsigned short' left can result in sign
          extension errors, since the C integer promotion rules means that the
          unsigned char/short will get implicitly promoted to a signed 'int' due to
          the shift (or due to other operations).
      
          This normally doesn't matter, but if you shift things up sufficiently, it
          will now set the sign bit in 'int', and a subsequent cast to a bigger type
          (eg 'long' or 'unsigned long') will now sign-extend the value despite the
          original expression being unsigned.
      
          One example of this would be something like
      
                  unsigned long size;
                  unsigned char c;
      
                  size += c << 24;
      
          where despite all the variables being unsigned, 'c << 24' ends up being a
          signed entity, and will get sign-extended when then doing the addition in
          an 'unsigned long' type.
      
          Since git uses 'unsigned char' pointers extensively, we actually have this
          bug in a couple of places.
      
      In our delta code, we inherited such a bogus shift when computing the
      offset at which the delta base is to be found. Due to the sign extension
      we can end up with an offset where all the bits are set. This can allow
      an arbitrary memory read, as the addition in `base_len < off + len` can
      now overflow if `off` has all its bits set.
      
      Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
      integer again. Add a test with a crafted delta that would actually
      succeed with an out-of-bounds read in case where the cast wouldn't
      exist.
      
      Reported-by: Riccardo Schirone <rschiron@redhat.com>
      Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
      Patrick Steinhardt committed
  32. 18 Jun, 2018 1 commit
  33. 10 Jun, 2018 1 commit