summaryrefslogtreecommitdiff
path: root/src/apply.c
Commit message (Collapse)AuthorAgeFilesLines
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
* apply: use GIT_ASSERTEdward Thomson2020-11-251-7/+16
|
* Make the tests run cleanly under UndefinedBehaviorSanitizerlhchavez2020-06-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This change makes the tests run cleanly under `-fsanitize=undefined,nullability` and comprises of: * Avoids some arithmetic with NULL pointers (which UBSan does not like). * Avoids an overflow in a shift, due to an uint8_t being implicitly converted to a signed 32-bit signed integer after being shifted by a 32-bit signed integer. * Avoids a unaligned read in libgit2. * Ignores unaligned reads in the SHA1 library, since it only happens on Intel processors, where it is _still_ undefined behavior, but the semantics are moderately well-understood. Of notable omission is `-fsanitize=integer`, since there are lots of warnings in zlib and the SHA1 library which probably don't make sense to fix and I could not figure out how to silence easily. libgit2 itself also has ~100s of warnings which are mostly innocuous (e.g. use of enum constants that only fit on an `uint32_t`, but there is no way to do that in a simple fashion because the data type chosen for enumerated types is implementation-defined), and investigating whether there are worrying warnings would need reducing the noise significantly.
* git_pool_init: handle failure casesethomson/poolinitEdward Thomson2020-06-011-1/+2
| | | | Propagate failures caused by pool initialization errors.
* global: DRY includes of assert.hEtienne Samson2019-11-061-2/+0
|
* apply: add GIT_APPLY_CHECKDrew DeVault2019-10-221-3/+7
| | | | | This adds an option which will check if a diff is applicable without actually applying it; equivalent to git apply --check.
* Merge pull request #5209 from mkostyuk/apply-wrong-patchEdward Thomson2019-09-091-1/+1
|\ | | | | apply: Fix a patch corruption related to EOFNL handling
| * apply: Fix a patch corruption related to EOFNL handlingMax Kostyukevich2019-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Use of apply's API can lead to an improper patch application and a corruption of the modified file. The issue is caused by mishandling of the end of file changes if there are several hunks to apply. The new line character is added to a line from a wrong hunk. The solution is to modify apply_hunk() to add the newline character at the end of a line from a right hunk.
* | apply: git_apply_to_tree fails to apply patches that add new filesMax Kostyukevich2019-08-201-3/+6
|/ | | | | | | | | git_apply_to_tree() cannot be used apply patches with new files. An attempt to apply such a patch fails because git_apply_to_tree() tries to remove a non-existing file from an old index. The solution is to modify git_apply_to_tree() to git_index_remove() when the patch states that the modified files is removed.
* apply: remove use of variadic error macroPatrick Steinhardt2019-08-011-3/+12
| | | | | | The macro `apply_err` is implemented as a variadic macro, which are not defined by C89. Convert it to a variadic function, instead.
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-201-1/+1
| | | | | | | | | Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
* patch_parse: ensure valid patch output with EOFNLErik Aigner2019-07-111-1/+8
|
* apply: refactor to use a switch statementPatrick Steinhardt2019-07-111-10/+14
|
* blob: add underscore to `from` functionsEdward Thomson2019-06-161-1/+1
| | | | | | The majority of functions are named `from_something` (with an underscore) instead of `fromsomething`. Update the blob functions for consistency with the rest of the library.
* apply: add an options struct initializerethomson/opts_initEdward Thomson2019-06-141-0/+7
|
* Merge pull request #4901 from pks-t/pks/uniform-map-apiEdward Thomson2019-02-221-5/+3
|\ | | | | High-level map APIs
| * maps: use high-level function to check existence of keysPatrick Steinhardt2019-02-151-3/+1
| | | | | | | | | | | | Some callers were still using the tightly-coupled pattern of `lookup_index` and `valid_index` to verify that an entry exists in a map. Instead, use the more high-level `exists` functions to decouple map users from its implementation.
| * strmap: introduce high-level setter for key/value pairsPatrick Steinhardt2019-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Currently, one would use the function `git_strmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_strmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_strmap_insert` to make use of it.
| * maps: use uniform lifecycle management functionsPatrick Steinhardt2019-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
* | apply: prevent OOB read when parsing source bufferErik Aigner2019-02-211-1/+1
|/ | | | | | | | | | | | | | | | | | | When parsing the patch image from a string, we split the string by newlines to get a line-based view of it. To split, we use `memchr` on the buffer and limit the buffer length by the original length provided by the caller. This works just fine for the first line, but for every subsequent line we need to actually subtract the amount of bytes that we have already read. The above issue can be easily triggered by having a source buffer with at least two lines, where the second line does _not_ end in a newline. Given a string "foo\nb", we have an original length of five bytes. After having extracted the first line, we will point to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an out-of-bounds read of four bytes. Fix the issue by correctly subtracting the amount of bytes already read.
* apply: make update_hunk accept a size_tEdward Thomson2019-01-251-1/+1
|
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-5/+5
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* Fix Linux warningslhchavez2019-01-081-1/+1
| | | | | This change fixes -Wmaybe-uninitialized and -Wdeprecated-declarations warnings on Linux builds
* Merge pull request #4847 from noahp/noahp/null-arg-fixesEdward Thomson2018-11-181-1/+2
|\ | | | | tests: 🌀 address two null argument instances
| * tests: address two null argument instancesNoah Pendleton2018-11-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* | apply: test re-adding a file after removing itEdward Thomson2018-11-051-10/+13
| | | | | | | | | | | | 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-051-12/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: handle multiple deltas to the same fileEdward Thomson2018-11-051-7/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: handle exact renamesEdward Thomson2018-11-051-2/+7
| | | | | | | | | | | | | | 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: introduce a hunk callbackEdward Thomson2018-11-051-7/+41
| | | | | | | | | | Introduce a callback to patch application that allows consumers to cancel hunk application.
* | apply: introduce a delta callbackEdward Thomson2018-11-051-3/+15
| | | | | | | | | | | | | | 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-051-10/+16
| | | | | | | | | | | | | | | | 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: validate workdir contents match index for BOTHEdward Thomson2018-11-051-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-1/+1
| | | | | | | | | | When using a workdir reader, optionally validate that the index contents match the working directory contents.
* | apply: use preimage as the checkout baselineEdward Thomson2018-11-051-28/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 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: 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: 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: return a specific exit code on failureEdward Thomson2018-11-041-1/+1
| | | | | | | | | | | | 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: handle file additionsEdward Thomson2018-11-041-3/+7
| | | | | | | | | | | | 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.
* | apply: handle file deletionsEdward Thomson2018-11-041-0/+3
| | | | | | | | | | | | 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.
* | apply: introduce `git_apply`Edward Thomson2018-11-041-0/+110
| | | | | | | | | | | | Introduce `git_apply`, which will take a `git_diff` and apply it to the working directory (akin to `git apply`), the index (akin to `git apply --cached`), or both (akin to `git apply --index`).
* | apply: reimplement `git_apply_tree` with readersEdward Thomson2018-11-041-16/+21
| | | | | | | | | | The generic `git_reader` interface simplifies `git_apply_tree` somewhat. Reimplement `git_apply_tree` with them.
* | apply: introduce `git_apply_tree`Edward Thomson2018-11-031-0/+100
|/ | | | | Introduce `git_apply_tree`, which will apply a `git_diff` to a given `git_tree`, allowing an in-memory patch application for a repository.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-4/+4
|
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
* giterr_set: consistent error messagesEdward Thomson2016-12-291-2/+2
| | | | | | | | Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
* common: use PRIuZ for size_t in `giterr_set` callsPatrick Steinhardt2016-11-141-1/+1
|
View Lorry Controller Status