1. 06 Nov, 2019 1 commit
  2. 22 Oct, 2019 1 commit
  3. 20 Aug, 2019 2 commits
    • apply: git_apply_to_tree fails to apply patches that add new files · de4bc2bd
      git_apply_to_tree() cannot be used apply patches with new files. An attempt
      to apply such a patch fails because git_apply_to_tree() tries to remove a
      non-existing file from an old index.
      
      The solution is to modify git_apply_to_tree() to git_index_remove() when the
      patch states that the modified files is removed.
      Max Kostyukevich committed
    • apply: Fix a patch corruption related to EOFNL handling · 630127e3
      Use of apply's API can lead to an improper patch application and a corruption
      of the modified file.
      
      The issue is caused by mishandling of the end of file changes if there are
      several hunks to apply. The new line character is added to a line from a wrong
      hunk.
      
      The solution is to modify apply_hunk() to add the newline character at the end
      of a line from a right hunk.
      Max Kostyukevich committed
  4. 01 Aug, 2019 1 commit
  5. 20 Jul, 2019 1 commit
  6. 11 Jul, 2019 2 commits
  7. 15 Jun, 2019 1 commit
  8. 14 Jun, 2019 1 commit
  9. 21 Feb, 2019 1 commit
    • apply: prevent OOB read when parsing source buffer · 014d4955
      When parsing the patch image from a string, we split the string
      by newlines to get a line-based view of it. To split, we use
      `memchr` on the buffer and limit the buffer length by the
      original length provided by the caller. This works just fine for
      the first line, but for every subsequent line we need to actually
      subtract the amount of bytes that we have already read.
      
      The above issue can be easily triggered by having a source buffer
      with at least two lines, where the second line does _not_ end in
      a newline. Given a string "foo\nb", we have an original length of
      five bytes. After having extracted the first line, we will point
      to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an
      out-of-bounds read of four bytes.
      
      Fix the issue by correctly subtracting the amount of bytes
      already read.
      Erik Aigner committed
  10. 15 Feb, 2019 3 commits
    • maps: use high-level function to check existence of keys · c50a8ac2
      Some callers were still using the tightly-coupled pattern of `lookup_index` and
      `valid_index` to verify that an entry exists in a map. Instead, use the more
      high-level `exists` functions to decouple map users from its implementation.
      Patrick Steinhardt committed
    • strmap: introduce high-level setter for key/value pairs · 03555830
      Currently, one would use the function `git_strmap_insert` to insert key/value
      pairs into a map. This function has historically been a macro, which is why its
      syntax is kind of weird: instead of returning an error code directly, it instead
      has to be passed a pointer to where the return value shall be stored. This does
      not match libgit2's common idiom of directly returning error codes.
      
      Introduce a new function `git_strmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert all callers of
      `git_strmap_insert` to make use of it.
      Patrick Steinhardt committed
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  11. 25 Jan, 2019 1 commit
  12. 22 Jan, 2019 1 commit
  13. 09 Jan, 2019 1 commit
  14. 13 Nov, 2018 1 commit
    • tests: address two null argument instances · f127ce35
      Handle two null argument cases that occur in the unit tests.
      One is in library code, the other is in test code.
      
      Detected by running unit tests with undefined behavior sanitizer:
      ```bash
       # build
      mkdir build && cd build
      cmake -DBUILD_CLAR=ON -DCMAKE_C_FLAGS="-fsanitize=address \
      -fsanitize=undefined -fstack-usage -static-libasan" ..
      cmake --build .
      
       # run with asan
      ASAN_OPTIONS="allocator_may_return_null=1" ./libgit2_clar
      ...
      ............../libgit2/src/apply.c:316:3: runtime error: null pointer \
      passed as argument 1, which is declared to never be null
      ...................../libgit2/tests/apply/fromfile.c:46:3: runtime \
      error: null pointer passed as argument 1, which is declared to never be null
      ```
      Noah Pendleton committed
  15. 05 Nov, 2018 14 commits
    • apply: test re-adding a file after removing it · f8b9493b
      Ensure that we can add a file back after it's been removed.  Update the
      renamed/deleted validation in application to not apply to deltas that
      are adding files to support this.
      Edward Thomson committed
    • apply: test modifying a file after renaming it · 78580ad3
      Ensure that we cannot modify a file after it's been renamed out of the
      way.  If multiple deltas exist for a single path, ensure that we do not
      attempt to modify a file after it's been renamed out of the way.
      
      To support this, we must track the paths that have been removed or
      renamed; add to a string map when we remove a path and remove from the
      string map if we recreate a path.  Validate that we are not applying to
      a path that is in this map, unless the delta is a rename, since git
      supports renaming one file to two different places in two different
      deltas.
      
      Further, test that we cannot apply a modification delta to a path that
      will be created in the future by a rename (a path that does not yet
      exist.)
      Edward Thomson committed
    • apply: handle multiple deltas to the same file · df4258ad
      git allows a patch file to contain multiple deltas to the same file:
      although it does not produce files in this format itself, this could
      be the result of concatenating two different patch files that affected
      the same file.
      
      git apply behaves by applying this next delta to the existing postimage
      of the file.  We should do the same.  If we have previously seen a file,
      and produced a postimage for it, we will load that postimage and apply
      the current delta to that.  If we have not, get the file from the
      preimage.
      Edward Thomson committed
    • apply: handle exact renames · 6fecf4d1
      Deltas containing exact renames are special; they simple indicate that a
      file was renamed without providing additional metadata (like the
      filemode).  Teach the reader to provide the file mode and use the
      preimage's filemode in the case that the delta does not provide one.)
      Edward Thomson committed
    • apply: introduce a hunk callback · 47cc5f85
      Introduce a callback to patch application that allows consumers to
      cancel hunk application.
      Edward Thomson committed
    • apply: introduce a delta callback · af33210b
      Introduce a callback to the application options that allow callers to
      add a per-delta callback.  The callback can return an error code to stop
      patch application, or can return a value to skip the application of a
      particular delta.
      Edward Thomson committed
    • apply: move location to an argument, not the opts · 37b25ac5
      Move the location option to an argument, out of the options structure.
      This allows the options structure to be re-used for functions that don't
      need to know the location, since it's implicit in their functionality.
      For example, `git_apply_tree` should not take a location, but is
      expected to take all the other options.
      Edward Thomson committed
    • apply: use an indexwriter · 2d27ddc0
      Place the entire `git_apply` operation inside an indexwriter, so that we
      lock the index before we begin performing patch application.  This
      ensures that there are no other processes modifying things in the
      working directory.
      Edward Thomson committed
    • apply: validate workdir contents match index for BOTH · 813f0802
      When applying to both the index and the working directory, ensure that
      the index contents match the working directory.  This mirrors the
      requirement in `git apply --index`.
      
      This also means that - along with the prior commit that uses the working
      directory contents as the checkout baseline - we no longer expect
      conflicts during checkout.  So remove the special-case error handling
      for checkout conflicts.  (Any checkout conflict now would be because the
      file was actually modified between the start of patch application and
      the checkout.)
      Edward Thomson committed
    • reader: optionally validate index matches workdir · 0f4b2f02
      When using a workdir reader, optionally validate that the index contents
      match the working directory contents.
      Edward Thomson committed
    • apply: use preimage as the checkout baseline · 5b8d5a22
      Use the preimage as the checkout's baseline.  This allows us to support
      applying patches to files that are modified in the working directory
      (those that differ from the HEAD and index).  Without this, files will
      be reported as (checkout) conflicts.  With this, we expect the on-disk
      data when we began the patch application (the "preimage") to be on-disk
      during checkout.
      
      We could have also simply used the `FORCE` flag to checkout to
      accomplish a similar mechanism.  However, `FORCE` ignores all
      differences, while providing a preimage ensures that we will only
      overwrite the file contents that we actually read.
      
      Modify the reader interface to provide the OID to support this.
      Edward Thomson committed
    • apply: convert checkout conflicts to apply failures · dddfff77
      When there's a checkout conflict during apply, that means that the
      working directory was modified in a conflicting manner and the postimage
      cannot be written.  During application, convert this to an application
      failure for consistency across workdir/index/both applications.
      Edward Thomson committed
    • apply: when preimage file is missing, return EAPPLYFAIL · 5b66b667
      The preimage file being missing entirely is simply a case of an
      application failure; return the correct error value for the caller.
      Edward Thomson committed
    • apply: simplify checkout vs index application · e0224121
      Separate the concerns of applying via checkout and updating the
      repository's index.  This results in simpler functionality and allows us
      to not build the temporary collection of paths in the index case.
      Edward Thomson committed
  16. 04 Nov, 2018 6 commits
  17. 03 Nov, 2018 1 commit
  18. 10 Jun, 2018 1 commit