summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* index: introduce git_index_iteratorethomson/index_iteratorEdward Thomson2018-11-145-3/+184
| | | | | | Provide a public git_index_iterator API that is backed by an index snapshot. This allows consumers to provide a stable iteration even while manipulating the index during iteration.
* Merge pull request #4705 from libgit2/ethomson/applyEdward Thomson2018-11-1121-21/+3697
|\ | | | | Patch (diff) application
| * test: ensure applying a patch can't delete a file twiceethomson/applyEdward Thomson2018-11-052-0/+45
| |
| * apply: test re-adding a file after removing itEdward Thomson2018-11-053-10/+63
| | | | | | | | | | | | 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.
| * apply: test modifying a file after renaming itEdward Thomson2018-11-053-12/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
| * apply: test renaming a file after modifying itEdward Thomson2018-11-052-5/+20
| | | | | | | | | | | | | | | | | | | | 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.
| * apply: test that we can't rename a file after modifying itEdward Thomson2018-11-052-0/+36
| | | | | | | | | | | | | | | | | | 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.
| * apply: test modify delta after rename deltaEdward Thomson2018-11-052-0/+50
| | | | | | | | Ensure that we can apply a delta after renaming a file.
| * apply: test multiple deltas to new fileEdward Thomson2018-11-052-0/+43
| |
| * apply: handle multiple deltas to the same fileEdward Thomson2018-11-053-7/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * apply: test rename 1 to 2Edward Thomson2018-11-052-0/+36
| | | | | | | | | | | | | | 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.
| * apply: test rename 2 to 1Edward Thomson2018-11-052-0/+34
| | | | | | | | | | | | | | 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.
| * apply: test circular renameEdward Thomson2018-11-052-0/+35
| | | | | | | | Test a rename from A->B simultaneous with a rename from B->A.
| * apply: test rename A -> B -> C scenariosEdward Thomson2018-11-052-0/+142
| | | | | | | | | | | | | | 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.
| * apply: handle exact renamesEdward Thomson2018-11-055-4/+54
| | | | | | | | | | | | | | 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.)
| * apply: validate unchanged mode when applying bothEdward Thomson2018-11-052-0/+30
| | | | | | | | | | | | | | 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.
| * apply: test a patch with rename and modificationEdward Thomson2018-11-052-0/+40
| | | | | | | | | | Create a test applying a patch with a rename and a modification of a file.
| * patch: add tests for aborting hunk callbackJason Haslam2018-11-051-0/+71
| |
| * patch: add support for partial patch applicationJason Haslam2018-11-053-0/+313
| | | | | | | | Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.
| * reader: free is unused and unnecessaryEdward Thomson2018-11-052-20/+0
| | | | | | | | | | None of the reader implementations actually allocate anything themselves, so they don't need a free function. Remove it.
| * apply: introduce a hunk callbackEdward Thomson2018-11-056-10/+101
| | | | | | | | | | Introduce a callback to patch application that allows consumers to cancel hunk application.
| * apply tests: tests a diff w/ many small changesEdward Thomson2018-11-052-0/+112
| |
| * apply tests: test delta callback skipEdward Thomson2018-11-051-0/+38
| | | | | | | | | | Test that we can return a non-zero value from the apply delta callback and it will skip the application of a given delta.
| * apply tests: test delta callback errorsEdward Thomson2018-11-051-0/+52
| | | | | | | | | | Test that we can return an error from the apply delta callback and the error code is propagated back to the caller.
| * apply: introduce a delta callbackEdward Thomson2018-11-052-3/+34
| | | | | | | | | | | | | | 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.
| * apply: move location to an argument, not the optsEdward Thomson2018-11-056-108/+66
| | | | | | | | | | | | | | | | 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.
| * apply: use an indexwriterEdward Thomson2018-11-051-3/+15
| | | | | | | | | | | | | | 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.
| * apply tests: ensure mode changes occurEdward Thomson2018-11-053-0/+62
| | | | | | | | Test that a mode change is reflected in the working directory or index.
| * apply tests: test with CR/LF filteringEdward Thomson2018-11-051-0/+53
| | | | | | | | | | | | 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.
| * reader: apply working directory filtersEdward Thomson2018-11-051-2/+13
| | | | | | | | | | | | | | | | When reading a file from the working directory, ensure that we apply any necessary filters to the item. This ensures that we get the repository-normalized data as the preimage, and further ensures that we can accurately compare the working directory contents to the index contents for accurate safety validation in the `BOTH` case.
| * apply: validate workdir contents match index for BOTHEdward Thomson2018-11-052-17/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
| * reader: optionally validate index matches workdirEdward Thomson2018-11-053-11/+37
| | | | | | | | | | When using a workdir reader, optionally validate that the index contents match the working directory contents.
| * apply tests: ensure we can patch a modified fileEdward Thomson2018-11-054-0/+125
| | | | | | | | | | | | | | | | 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.
| * apply: use preimage as the checkout baselineEdward Thomson2018-11-053-32/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * apply tests: test index+workdir applicationEdward Thomson2018-11-051-0/+281
| | | | | | | | | | | | Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates `git apply --index`, updating both the index and the working directory with the postimage.
| * apply: convert checkout conflicts to apply failuresEdward Thomson2018-11-051-0/+7
| | | | | | | | | | | | | | 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.
| * apply test: apply with non-conflicting changesEdward Thomson2018-11-052-0/+70
| | | | | | | | | | | | 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.
| * apply tests: ensure apply failures leave index unmodifiedEdward Thomson2018-11-051-0/+34
| |
| * apply: when preimage file is missing, return EAPPLYFAILEdward Thomson2018-11-051-1/+7
| | | | | | | | | | The preimage file being missing entirely is simply a case of an application failure; return the correct error value for the caller.
| * apply: simplify checkout vs index applicationEdward Thomson2018-11-051-77/+126
| | | | | | | | | | | | 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.
| * apply tests: modified wd items are ok when applying to indexEdward Thomson2018-11-041-0/+43
| | | | | | | | | | | | When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure that items modified in the working directory do not conflict with the application.
| * apply tests: ensure we can add and remove files from the indexEdward Thomson2018-11-041-0/+56
| | | | | | | | | | 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.
| * apply: remove deleted paths from indexEdward Thomson2018-11-041-0/+19
| | | | | | | | | | | | We update the index with the new_file side of the delta, but we need to explicitly remove the old_file path in the case where an item was deleted or renamed.
| * apply tests: GIT_APPLY_LOCATION_INDEX with parsed patchesEdward Thomson2018-11-041-0/+28
| |
| * apply tests: GIT_APPLY_LOCATION_INDEX with generated patchesEdward Thomson2018-11-042-0/+94
| | | | | | | | | | Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which emulates `git apply --cached`.
| * apply tests: move helpers into common areaEdward Thomson2018-11-042-152/+155
| |
| * apply: test that failures don't dirty workdirEdward Thomson2018-11-041-0/+29
| | | | | | | | | | | | | | | | | | | | 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.
| * apply: return a specific exit code on failureEdward Thomson2018-11-042-1/+2
| | | | | | | | | | | | Return `GIT_EAPPLYFAIL` on patch application failure so that users can determine that patch application failed due to a malformed/conflicting patch by looking at the error code.
| * apply: test a patch can be applied even with a modified indexEdward Thomson2018-11-041-22/+15
| | | | | | | | | | | | | | 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).
| * apply: test that the index is not modifiedEdward Thomson2018-11-041-0/+76
| | | | | | | | | | Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that patch application does not update the index, only the working directory.
View Lorry Controller Status