1. 05 Jan, 2022 1 commit
  2. 10 Dec, 2021 1 commit
  3. 11 Nov, 2021 1 commit
  4. 09 Nov, 2021 1 commit
  5. 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
  6. 18 Sep, 2021 2 commits
  7. 18 May, 2021 1 commit
  8. 13 May, 2021 1 commit
  9. 11 May, 2021 1 commit
  10. 16 Sep, 2020 1 commit
  11. 29 Aug, 2020 1 commit
  12. 05 Jun, 2020 2 commits
  13. 23 May, 2020 1 commit
  14. 18 Apr, 2020 1 commit
  15. 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
  16. 28 Nov, 2019 1 commit
  17. 16 Oct, 2019 1 commit
  18. 28 Sep, 2019 1 commit
  19. 20 Jul, 2019 1 commit
  20. 18 Jul, 2019 1 commit
  21. 15 Jun, 2019 1 commit
  22. 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
  23. 06 Apr, 2019 1 commit
  24. 29 Mar, 2019 1 commit
  25. 22 Jan, 2019 1 commit
  26. 01 Dec, 2018 2 commits
  27. 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
  28. 06 Jul, 2018 1 commit
  29. 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
  30. 18 Jun, 2018 1 commit
  31. 10 Jun, 2018 1 commit
  32. 05 May, 2018 1 commit
  33. 05 Apr, 2018 1 commit
  34. 20 Feb, 2018 2 commits
    • diff_tform: fix rename detection with rewrite/delete pair · ce7080a0
      A rewritten file can either be classified as a modification of its
      contents or of a delete of the complete file followed by an addition of
      the new content. This distinction becomes important when we want to
      detect renames for rewrites. Given a scenario where a file "a" has been
      deleted and another file "b" has been renamed to "a", this should be
      detected as a deletion of "a" followed by a rename of "a" -> "b". Thus,
      splitting of the original rewrite into a delete/add pair is important
      here.
      
      This splitting is represented by a flag we can set at the current delta.
      While the flag is already being set in case we want to break rewrites,
      we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES`
      flag is set. This can trigger an assert when we try to match the source
      and target deltas.
      
      Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta
      when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is
      set.
      Patrick Steinhardt committed
    • tests: add rename-rewrite scenarios to "renames" repository · 80e77b87
      Add two more scenarios to the "renames" repository. The first scenario
      has a major rewrite of a file and a delete of another file, the second
      scenario has a deletion of a file and rename of another file to the
      deleted file. Both scenarios will be used in the following commit.
      Patrick Steinhardt committed