tests/patch


Log

Author Commit Date CI Message
Max Kostyukevich 585fbd74 2019-08-28T23:18:31 apply: Test for EOFNL mishandling when several hunks are processed Introduce an unit test to validate that git_apply__patch() properly handles EOFNL changes in case of patches with several hunks.
Edward Thomson fd7a384b 2019-07-20T11:24:37 Merge pull request #5159 from pks-t/pks/patch-parse-old-missing-nl patch_parse: handle missing newline indicator in old file
Erik Aigner b0893282 2019-07-11T12:12:04 patch_parse: ensure valid patch output with EOFNL
Patrick Steinhardt 3f855fe8 2019-07-05T11:06:33 patch_parse: handle missing newline indicator in old file When either the old or new file contents have no newline at the end of the file, then git-diff(1) will print out a "\ No newline at end of file" indicator. While we do correctly handle this in the case where the new file has this indcator, we fail to parse patches where the old file is missing a newline at EOF. Fix this bug by handling and missing newline indicators in the old file. Add tests to verify that we can parse such files.
Patrick Steinhardt dedf70ad 2019-07-05T09:35:43 patch_parse: do not depend on parsed buffer's lifetime When parsing a patch from a buffer, we let the patch lines point into the original buffer. While this is efficient use of resources, this also ties the lifetime of the parsed patch to the parsed buffer. As this behaviour is not documented anywhere in our API it is very surprising to its users. Untie the lifetime by duplicating the lines into the parsed patch. Add a test that verifies that lifetimes are indeed independent of each other.
Drew DeVault 30c06b60 2019-03-22T23:56:10 patch_parse.c: Handle CRLF in parse_header_start
Erik Aigner 9d65360b 2019-03-29T12:30:37 tests: diff: test parsing diffs with a new file with spaces in its path Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
Jason Haslam 72630572 2017-03-30T22:40:47 patch: add support for partial patch application Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Patrick Steinhardt 80226b5f 2017-09-22T13:39:05 patch_parse: allow parsing ambiguous patch headers The git patch format allows for having unquoted paths with whitespaces inside. This format becomes ambiguous to parse, e.g. in the following example: diff --git a/file b/with spaces.txt b/file b/with spaces.txt While we cannot parse this in a correct way, we can instead use the "---" and "+++" lines to retrieve the file names, as the path is not followed by anything here but spans the complete remaining line. Because of this, we can simply bail outwhen parsing the "diff --git" header here without an actual error and then proceed to just take the paths from the other headers.
Patrick Steinhardt 89a34828 2017-06-16T13:34:43 diff: implement function to calculate patch ID 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.
Edward Thomson adedac5a 2016-09-02T02:03:45 diff: treat binary patches with no data special When creating and printing diffs, deal with binary deltas that have binary data specially, versus diffs that have a binary file but lack the actual binary data.
Edward Thomson 94e488a0 2016-04-24T16:14:25 patch: differentiate not found and invalid patches
Edward Thomson 17572f67 2016-04-21T00:04:14 git_patch_parse_ctx: refcount the context
Edward Thomson 440e3bae 2015-11-21T12:27:03 patch: `git_patch_from_patchfile` -> `git_patch_from_buffer`
Edward Thomson 0ff723cc 2015-09-25T12:09:50 apply: test postimages that grow/shrink original Test with some postimages that actually grow/shrink from the original, adding new lines or removing them. (Also do so without context to ensure that we can add/remove from a non-zero part of the line vector.)
Edward Thomson 82175084 2015-09-23T13:40:12 Introduce git_patch_options, handle prefixes Handle prefixes (in terms of number of path components) for patch parsing.
Edward Thomson 2f3b922f 2015-09-22T18:54:10 patch_parse: test roundtrip patch parsing -> print
Edward Thomson 42b34428 2015-09-22T18:54:10 patch_parse: ensure we can parse a patch
Edward Thomson 8bca8b9e 2015-09-16T14:40:44 apply: move patch data to patch_common.h