kmx git

Commit	Date	Message
dbc03de4	2021-03-20T14:28:25	apply: ensure we validate paths There was no test ensuring that we validate `.git` paths. We do, but let's add a test to make sure that we never regress this.
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.)
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.
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.
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.

dbc03de4

2021-03-20T14:28:25

apply: ensure we validate paths There was no test ensuring that we validate `.git` paths. We do, but let's add a test to make sure that we never regress this.

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.)

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.

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.

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.

thodg/libgit2/tests/apply/both.c

tests/apply/both.c

Log