1. 15 Dec, 2017 1 commit
    • diff_file: properly refcount blobs when initializing file contents · 2388a9e2
      When initializing a `git_diff_file_content` from a source whose data is
      derived from a blob, we simply assign the blob's pointer to the
      resulting struct without incrementing its refcount. Thus, the structure
      can only be used as long as the blob is kept alive by the caller.
      
      Fix the issue by using `git_blob_dup` instead of a direct assignment.
      This function will increment the refcount of the blob without allocating
      new memory, so it does exactly what we want. As
      `git_diff_file_content__unload` already frees the blob when
      `GIT_DIFF_FLAG__FREE_BLOB` is set, we don't need to add new code
      handling the free but only have to set that flag correctly.
      Patrick Steinhardt committed
  2. 01 Sep, 2017 1 commit
  3. 26 Jun, 2017 1 commit
    • diff: implement function to calculate patch ID · 89a34828
      The upstream git project provides the ability to calculate a so-called
      patch ID. Quoting from git-patch-id(1):
      
          A "patch ID" is nothing but a sum of SHA-1 of the file diffs
          associated with a patch, with whitespace and line numbers ignored."
      
      Patch IDs can be used to identify two patches which are probably the
      same thing, e.g. when a patch has been cherry-picked to another branch.
      
      This commit implements a new function `git_diff_patchid`, which gets a
      patch and derives an OID from the diff. Note the different terminology
      here: a patch in libgit2 are the differences in a single file and a diff
      can contain multiple patches for different files. The implementation
      matches the upstream implementation and should derive the same OID for
      the same diff. In fact, some code has been directly derived from the
      upstream implementation.
      
      The upstream implementation has two different modes to calculate patch
      IDs, which is the stable and unstable mode. The old way of calculating
      the patch IDs was unstable in a sense that a different ordering the
      diffs was leading to different results. This oversight was fixed in git
      1.9, but as git tries hard to never break existing workflows, the old
      and unstable way is still default. The newer and stable way does not
      care for ordering of the diff hunks, and in fact it is the mode that
      should probably be used today. So right now, we only implement the
      stable way of generating the patch ID.
      Patrick Steinhardt committed
  4. 14 Mar, 2017 3 commits
    • diff_parse: correctly set options for parsed diffs · c0eba379
      The function `diff_parsed_alloc` allocates and initializes a
      `git_diff_parsed` structure. This structure also contains diff options.
      While we initialize its flags, we fail to do a real initialization of
      its values. This bites us when we want to actually use the generated
      diff as we do not se the option's version field, which is required to
      operate correctly.
      
      Fix the issue by executing `git_diff_init_options` on the embedded
      struct.
      Patrick Steinhardt committed
    • patch_parse: fix parsing minimal trailing diff line · ad5a909c
      In a diff, the shortest possible hunk with a modification (that is, no
      deletion) results from a file with only one line with a single character
      which is removed. Thus the following hunk
      
          @@ -1 +1 @@
          -a
          +
      
      is the shortest valid hunk modifying a line. The function parsing the
      hunk body though assumes that there must always be at least 4 bytes
      present to make up a valid hunk, which is obviously wrong in this case.
      The absolute minimum number of bytes required for a modification is
      actually 2 bytes, that is the "+" and the following newline. Note: if
      there is no trailing newline, the assumption will not be offended as the
      diff will have a line "\ No trailing newline" at its end.
      
      This patch fixes the issue by lowering the amount of bytes required.
      Patrick Steinhardt committed
    • patch_generate: fix `git_diff_foreach` only working with generated diffs · ace3508f
      The current logic of `git_diff_foreach` makes the assumption that all
      diffs passed in are actually derived from generated diffs. With these
      assumptions we try to derive the actual diff by inspecting either the
      working directory files or blobs of a repository. This obviously cannot
      work for diffs parsed from a file, where we do not necessarily have a
      repository at hand.
      
      Since the introduced split of parsed and generated patches, there are
      multiple functions which help us to handle patches generically, being
      indifferent from where they stem from. Use these functions and remove
      the old logic specific to generated patches. This allows re-using the
      same code for invoking the callbacks on the deltas.
      Patrick Steinhardt committed
  5. 09 Oct, 2016 1 commit
  6. 24 Aug, 2016 1 commit
  7. 26 Jun, 2016 4 commits
  8. 26 May, 2016 2 commits
  9. 02 Apr, 2016 1 commit
  10. 24 Mar, 2016 1 commit
  11. 23 Mar, 2016 3 commits
  12. 20 Mar, 2016 1 commit
  13. 03 Mar, 2016 1 commit
  14. 28 Feb, 2016 1 commit
  15. 12 Feb, 2016 1 commit
  16. 11 Feb, 2016 1 commit
  17. 01 Dec, 2015 1 commit
  18. 20 Nov, 2015 1 commit
  19. 03 Nov, 2015 1 commit
  20. 02 Nov, 2015 1 commit
  21. 21 Oct, 2015 1 commit
  22. 25 Sep, 2015 1 commit
    • Fix binary diffs · e4b2b919
      git expects an empty line after the binary data:
      
      literal X
      ...binary data...
      <empty_line>
      
      The last literal block of the generated patches were not containing the required empty line. Example:
      
      	diff --git a/binary_file b/binary_file
      	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 6
      	Nc${NM%g@i}0ssZ|0lokL
      	diff --git a/binary_file2 b/binary_file2
      	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 13
      	Sc${NMEKbZyOexL+Qd|HZV+4u-
      
      git apply of that diff results in:
      
      	error: corrupt binary patch at line 9: diff --git a/binary_file2 b/binary_file2
      	fatal: patch with only garbage at line 10
      
      The proper formating is:
      
      	diff --git a/binary_file b/binary_file
      	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 6
      	Nc${NM%g@i}0ssZ|0lokL
      	diff --git a/binary_file2 b/binary_file2
      	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 13
      	Sc${NMEKbZyOexL+Qd|HZV+4u-
      Guille -bisho- committed
  23. 12 Sep, 2015 1 commit
  24. 31 Aug, 2015 1 commit
    • iterator: saner pathlist matching for idx iterator · d53c8880
      Some nicer refactoring for index iteration walks.
      
      The index iterator doesn't binary search through the pathlist space,
      since it lacks directory entries, and would have to binary search
      each index entry and all its parents (eg, when presented with an index
      entry of `foo/bar/file.c`, you would have to look in the pathlist for
      `foo/bar/file.c`, `foo/bar` and `foo`).  Since the index entries and the
      pathlist are both nicely sorted, we walk the index entries in lockstep
      with the pathlist like we do for other iteration/diff/merge walks.
      Edward Thomson committed
  25. 30 Aug, 2015 1 commit
  26. 29 Aug, 2015 1 commit
  27. 28 Aug, 2015 1 commit
  28. 15 Aug, 2015 1 commit
  29. 30 Jun, 2015 1 commit
  30. 26 Jun, 2015 3 commits