1. 29 Mar, 2019 3 commits
    • tests: diff: test parsing diffs with a new file with spaces in its path · 9d65360b
      Add a test that verifies that we are able to parse patches which add a
      new file that has spaces in its path.
      Erik Aigner committed
    • patch_parse: fix parsing addition/deletion of file with space · b3497344
      The diff header format is a strange beast in that it is inherently
      unparseable in an unambiguous way. While parsing
      
          a/file.txt b/file.txt
      
      is obvious and trivially doable, parsing a diff header of
      
          a/file b/file ab.txt b/file b/file ab.txt
      
      is not (but in fact valid and created by git.git).
      
      Due to that, we have relaxed our diff header parser in commit 80226b5f
      (patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so
      that we started to bail out when seeing diff headers with spaces in
      their file names. Instead, we try to use the "---" and "+++" lines,
      which are unambiguous.
      
      In some cases, though, we neither have a useable file name from the
      header nor from the "---" or "+++" lines. This is the case when we have
      a deletion or addition of a file with spaces: the header is unparseable
      and the other lines will simply show "/dev/null". This trips our parsing
      logic when we try to extract the prefix (the "a/" part) that is being
      used in the path line, where we unconditionally try to dereference a
      NULL pointer in such a scenario.
      
      We can fix this by simply not trying to parse the prefix in cases where
      we have no useable path name. That'd leave the parsed patch without
      either `old_prefix` or `new_prefix` populated. But in fact such cases
      are already handled by users of the patch object, which simply opt to
      use the default prefixes in that case.
      Patrick Steinhardt committed
  2. 06 Mar, 2019 1 commit
  3. 05 Mar, 2019 1 commit
  4. 02 Mar, 2019 2 commits
  5. 28 Feb, 2019 2 commits
  6. 27 Feb, 2019 3 commits
  7. 25 Feb, 2019 2 commits
  8. 23 Feb, 2019 2 commits
    • odb: provide a free function for custom backends · 459ac856
      Custom backends can allocate memory when reading objects and providing
      them to libgit2.  However, if an error occurs in the custom backend
      after the memory has been allocated for the custom object but before
      it's returned to libgit2, the custom backend has no way to free that
      memory and it must be leaked.
      
      Provide a free function that corresponds to the alloc function so that
      custom backends have an opportunity to free memory before they return an
      error.
      Edward Thomson committed
    • odb: rename git_odb_backend_malloc for consistency · 790aae77
      The `git_odb_backend_malloc` name is a system function that is provided
      for custom ODB backends and allows them to allocate memory for an ODB
      object in the read callback.  This is important so that libgit2 can
      later free the memory used by an ODB object that was read from the
      custom backend.
      
      However, the name _suggests_ that it actually allocates a
      `git_odb_backend`.  It does not; rename it to make it clear that it
      actually allocates backend _data_.
      Edward Thomson committed
  9. 22 Feb, 2019 11 commits
  10. 21 Feb, 2019 12 commits
  11. 20 Feb, 2019 1 commit