|
02af1fcb
|
2019-09-14T14:03:36
|
|
apply: add GIT_APPLY_CHECK
This adds an option which will check if a diff is applicable without
actually applying it; equivalent to git apply --check.
|
|
c3a7892f
|
2019-09-09T13:10:24
|
|
Merge pull request #5209 from mkostyuk/apply-wrong-patch
apply: Fix a patch corruption related to EOFNL handling
|
|
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.
|
|
|
5498c318
|
2019-08-27T13:10:53
|
|
apply: free test data
|
|
|
dceedbb8
|
2019-08-21T15:03:50
|
|
apply: Test for git_apply_to_tree failures when new files are added
Introduce an unit test to validate if git_apply_to_tree() fails when an
applied patch adds new files.
|
|
966b9440
|
2019-02-21T08:30:22
|
|
tests: apply: verify that we correctly truncate the source buffer
Previously, we would fail to correctly truncate the source buffer
if the source has more than one line and ends with a non-newline
character. In the following call, we thus truncate the source
string in the middle of the second line. Without the bug fixed,
we would successfully apply the patch to the source and return
success. With the overflow being fixed, we should return an
error now.
|
|
|
18e71e6d
|
2018-11-28T13:31:06
|
|
index: use new enum and structure names
Use the new-style index names throughout our own codebase.
|
|
|
14a9a4f3
|
2018-11-21T11:18:46
|
|
tests: move apply_helpers functions into own compilation unit
Currently, the "apply_helper" functions used for testing the apply logic are all
statically defined in the "apply_helpers.h" header file. This may lead to
warnings from the compiler in case where this header file is included, but not
all functions it brings along are used in the compilation unit where it has been
included into.
Fix these potential warnings by moving the implementation into its own
compilation unit "apply_helpers.c".
|
|
|
646a94be
|
2018-11-18T23:15:56
|
|
Merge pull request #4847 from noahp/noahp/null-arg-fixes
tests: 🌀 address two null argument instances
|
|
f127ce35
|
2018-11-13T08:22:25
|
|
tests: address two null argument instances
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
```
|
|
|
afc64bcd
|
2018-11-13T14:13:40
|
|
tests: apply: fix reference to deprecated `git_buf_free`
Since commit 56ffdfc61 (buffer: deprecate `git_buf_free` in favor of
`git_buf_dispose`, 2018-02-08), the function `git_buf_free` is
deprecated and shall not be used anymore. As part of the new apply
framework that has been cooking for quite some time some new references
have been introduced to that deprecated function. Replace them with
calls to `git_buf_dispose`.
|
|
|
fe215153
|
2018-11-13T14:08:49
|
|
tests: apply: fix missing `cl_git_pass` wrappers
Some function calls in the new "apply" test suite were missing the
checks whether they succeeded as expected. Fix this by adding the
missing `cl_git_pass` wrappers.
|
|
|
4e746d80
|
2018-11-05T15:49:11
|
|
test: ensure applying a patch can't delete a file twice
|
|
|
f8b9493b
|
2018-11-05T15:46:08
|
|
apply: test re-adding a file after removing it
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.
|
|
|
78580ad3
|
2018-11-05T15:34:59
|
|
apply: test modifying a file after renaming it
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.)
|
|
|
47cc5f85
|
2018-09-29T19:32:51
|
|
apply: introduce a hunk callback
Introduce a callback to patch application that allows consumers to
cancel hunk application.
|
|
|
398d8bfe
|
2018-07-16T17:19:08
|
|
apply tests: tests a diff w/ many small changes
|
|
|
b8840db7
|
2018-07-10T16:18:45
|
|
apply tests: test delta callback skip
Test that we can return a non-zero value from the apply delta
callback and it will skip the application of a given delta.
|
|
|
db6b1164
|
2018-07-10T16:13:17
|
|
apply tests: test delta callback errors
Test that we can return an error from the apply delta callback and the
error code is propagated back to the caller.
|
|
|
605066ee
|
2018-11-05T14:37:35
|
|
apply: test renaming a file after modifying it
Multiple deltas can exist in a diff, and can be applied in-order.
If there exists a delta that modifies a file followed by a delta that
renames that file, then both will be captured. The modification delta
will be applied and the resulting file will be staged with the original
filename. The rename delta will be independently applied - to the
original file (not the modified file from the original delta) and staged
independently.
|
|
|
bd682f3e
|
2018-11-04T19:01:57
|
|
apply: test that we can't rename a file after modifying it
Multiple deltas can exist in a diff, and can be applied in-order.
However if there exists a delta that renames a file, it must be first,
so that other deltas can reference the resulting target file.
git enforces this (`error: already exists in index`), so ensure that we
do, too.
|
|
|
a3c1070c
|
2018-11-04T14:07:22
|
|
apply: test modify delta after rename delta
Ensure that we can apply a delta after renaming a file.
|
|
|
07e71bfa
|
2018-11-04T13:14:20
|
|
apply: test multiple deltas to new file
|
|
|
df4258ad
|
2018-11-04T13:01:03
|
|
apply: handle multiple deltas to the same file
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.
|
|
|
c71e964a
|
2018-11-04T12:21:57
|
|
apply: test rename 1 to 2
Test that a patch can contain two deltas that appear to rename an
initial source file to two different destination paths. Git creates
both target files with the initial source contents; ensure that we do,
too.
|
|
|
56a2ae0c
|
2018-11-04T12:18:01
|
|
apply: test rename 2 to 1
Test that we can apply a patch that renames two different files to the
same target filename. Git itself handles this scenario in a last-write
wins, such that the rename listed last is the one persisted in the
target. Ensure that we do the same.
|
|
|
235dc9b2
|
2018-11-04T12:05:46
|
|
apply: test circular rename
Test a rename from A->B simultaneous with a rename from B->A.
|
|
|
89b5a56e
|
2018-11-04T11:58:20
|
|
apply: test rename A -> B -> C scenarios
Test that we can rename some file from B->C and then rename some other
file from A->B. Do this with both exact rename patches (eg `rename from
...` / `rename to ...`) and patches that remove the files and replace
them entirely.
|
|
|
6fecf4d1
|
2018-11-04T11:47:46
|
|
apply: handle exact renames
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.)
|
|
|
12f9ac17
|
2018-11-04T11:26:42
|
|
apply: validate unchanged mode when applying both
When applying to both the index and the working directory, ensure that
the working directory's mode matches the index's mode. It's not
sufficient to look only at the hashed object id to determine that the
file is unchanged, git also takes the mode into account.
|
|
|
b73a42f6
|
2018-11-04T10:48:23
|
|
apply: test a patch with rename and modification
Create a test applying a patch with a rename and a modification of a
file.
|
|
620ac9c2
|
2017-04-11T14:41:57
|
|
patch: add tests for aborting hunk callback
|
|
|
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.
|
|
|
37b25ac5
|
2018-07-08T16:12:58
|
|
apply: move location to an argument, not the opts
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.
|
|
|
eb76e985
|
2018-07-01T21:21:25
|
|
apply tests: ensure mode changes occur
Test that a mode change is reflected in the working directory or index.
|
|
|
5c63ce79
|
2018-07-01T11:10:03
|
|
apply tests: test with CR/LF filtering
Ensure that we accurately CR/LF filter when reading from the working
directory. If we did not, we would erroneously fail to apply the patch
because the index contents did not match the working directory contents.
|
|
|
813f0802
|
2018-07-01T15:14:36
|
|
apply: validate workdir contents match index for BOTH
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.)
|
|
|
3b674660
|
2018-07-01T13:46:59
|
|
apply tests: ensure we can patch a modified file
Patch application need not be on an unmodified file; applying to an
already changed file is supported provided the patch still applies
cleanly. Add tests that modifies the contents of a file then applies
the patch and ensures that the patch applies cleanly, and the original
changes are also kept.
|
|
|
4ff829e9
|
2018-06-30T17:20:03
|
|
apply tests: test index+workdir application
Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates
`git apply --index`, updating both the index and the working directory
with the postimage.
|
|
|
9db66c79
|
2018-06-29T12:50:38
|
|
apply test: apply with non-conflicting changes
Ensure that we can apply to the working directory or the index when the
application target is modified, so long as there are not conflicting
changes to the items.
|
|
|
771bd81e
|
2018-06-29T12:40:16
|
|
apply tests: ensure apply failures leave index unmodified
|
|
|
2bd3cfea
|
2018-06-29T11:43:55
|
|
apply tests: modified wd items are ok when applying to index
When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure
that items modified in the working directory do not conflict with the
application.
|
|
|
d7090ee4
|
2018-06-28T17:26:24
|
|
apply tests: ensure we can add and remove files from the index
Add a test that adds a new file, and another that removes a file when
applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.
|
|
|
9d81defa
|
2018-06-28T16:26:08
|
|
apply tests: GIT_APPLY_LOCATION_INDEX with parsed patches
|
|
|
eef34e4e
|
2018-06-28T16:24:21
|
|
apply tests: GIT_APPLY_LOCATION_INDEX with generated patches
Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which
emulates `git apply --cached`.
|
|
|
c010c93b
|
2018-06-27T16:50:07
|
|
apply tests: move helpers into common area
|
|
|
35d525b0
|
2018-06-26T09:19:12
|
|
apply: test that failures don't dirty workdir
Ensure that when a patch application fails (due to a conflict in the
working directory, for example) that we do not half-apply the patch or
otherwise leave the working directory dirty.
This is rather obvious in our current apply implementation (we do a two
step process: one to create the post-image and one to check it out) but
this test is a safety net for future refactoring or improvements.
|
|
|
973bf0c8
|
2018-06-25T20:49:22
|
|
apply: test a patch can be applied even with a modified index
Ensure that we can apply a patch to the working directory, even to files
that are modified in the index (as long as the working directory
contents match the preimage - such that the working directory is
unmodified from HEAD).
|
|
|
553395dc
|
2018-06-25T20:21:01
|
|
apply: test that the index is not modified
Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that
patch application does not update the index, only the working directory.
|
|
|
0eb63b9f
|
2018-06-25T19:50:35
|
|
apply tests: separate common patch hunks
Move the commonly-used patch hunks into a single constant location.
This allows us to avoid re-declaring them in each test, and allows
us to compose them to build a larger patch file that includes all
the hunks.
|
|
|
702d4bec
|
2018-06-26T15:26:37
|
|
apply tests: use `git_iterator_foreach` for tests
Use the new `git_iterator_foreach` API to validate the workdir against
the expected workdir values instead of using the paired/multi iterator
comparison callback. This allows us to use the `git_iterator_foreach`
to validate the index as well, instead of assuming that the index and
HEAD must always match.
|
|
|
9c34c996
|
2018-06-25T17:03:14
|
|
apply: handle file additions
Don't attempt to read the postimage file during a file addition, simply
use an empty buffer as the postimage. Also, test that we can handle
file additions.
|
|
|
3b5378c5
|
2018-06-25T16:27:06
|
|
apply: handle file deletions
If the file was deleted in the postimage, do not attempt to update the
target. Instead, ignore it and simply allow it to stay removed in our
computed postimage. Also, test that we can handle file deletions.
|
|
|
af3287f8
|
2018-06-22T19:27:19
|
|
apply: test `git_apply` with a parsed patch
Ensure that we can apply a simple patch to the working directory when we
have parsed it from a patch file.
|
|
|
ff296b71
|
2018-03-19T19:50:52
|
|
apply: test `git_apply` application to a workdir
Introduce a standard test applying a diff to a working directory with no
complications.
|
|
|
02b1083a
|
2018-01-28T23:25:07
|
|
apply: introduce `git_apply_tree`
Introduce `git_apply_tree`, which will apply a `git_diff` to a given
`git_tree`, allowing an in-memory patch application for a repository.
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
17572f67
|
2016-04-21T00:04:14
|
|
git_patch_parse_ctx: refcount the context
|
|
|
440e3bae
|
2015-11-21T12:27:03
|
|
patch: `git_patch_from_patchfile` -> `git_patch_from_buffer`
|
|
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.)
|
|
|
82175084
|
2015-09-23T13:40:12
|
|
Introduce git_patch_options, handle prefixes
Handle prefixes (in terms of number of path components) for patch
parsing.
|
|
|
8bca8b9e
|
2015-09-16T14:40:44
|
|
apply: move patch data to patch_common.h
|
|
|
804d5fe9
|
2015-09-11T08:37:12
|
|
patch: abstract patches into diff'ed and parsed
Patches can now come from a variety of sources - either internally
generated (from diffing two commits) or as the results of parsing
some external data.
|
|
|
8d2eef27
|
2015-07-10T09:09:27
|
|
patch parsing: ensure empty patches are illegal
|
|
|
5d17d726
|
2015-07-09T19:22:28
|
|
patch parsing: parse binary patch files
|
|
|
3149ff6f
|
2015-06-17T18:13:10
|
|
patch application: apply binary patches
Handle the application of binary patches. Include tests that
produce a binary patch (an in-memory `git_patch` object),
then enusre that the patch applies correctly.
|
|
|
0004386f
|
2015-06-17T06:03:01
|
|
apply: handle empty patches
When a patch is empty, simply copy the source into the destination.
|
|
|
d34f6826
|
2014-04-08T17:18:47
|
|
Patch parsing from patch files
|
|
|
7cb904ba
|
2014-04-01T23:58:59
|
|
Introduce git_apply_patch
The beginnings of patch application from an existing (diff-created)
git_patch object: applies the hunks of a git_patch to a buffer.
|