- 17 Oct, 2021 1 commit
-
-
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.
Edward Thomson committed
-
- 29 Aug, 2020 1 commit
-
-
This follows up on 11de594f which added support for parsing patches without extended headers (the "index <hash>..<hash> <mode>" line); issue #5267. We now allow transition from "file mode" state to "path" state directly if there is no "index", which will happen for patches adding or deleting files as demonstrated in added test case.
Denis Laxalde committed
-
- 05 Jun, 2020 2 commits
-
-
Edward Thomson committed
-
We don't call any internal functions in the test; we don't need to include `../src/diff.h`.
Edward Thomson committed
-
- 16 Oct, 2019 1 commit
-
-
Extended header lines (especially the "index <hash>..<hash> <mode>") are not required by "git apply" so it import patches. So we allow the from-file/to-file lines (--- a/file\n+++ b/file) to directly follow the git diff header. This fixes #5267.
Denis Laxalde committed
-
- 28 Sep, 2019 1 commit
-
-
Patches containing additions of empty files will not contain diff data but will end with the index header line followed by the terminating sequence "-- ". We follow the same logic as in cc4c44a9 and allow "-- " to immediately follow the index header.
Denis Laxalde committed
-
- 06 Apr, 2019 1 commit
-
-
Drew DeVault committed
-
- 29 Mar, 2019 1 commit
-
-
Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
Erik Aigner committed
-
- 18 Jun, 2018 1 commit
-
-
Etienne Samson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 01 Sep, 2017 1 commit
-
-
Patches which contain exact renames only will not contain an actual diff body, but only a list of files that were renamed. Thus, the patch header is immediately followed by the terminating sequence "-- ". We currently do not recognize this character sequence as a possible terminating sequence. Add it and create a test to catch the failure.
Patrick Steinhardt committed
-
- 14 Mar, 2017 3 commits
-
-
The function `diff_parsed_alloc` allocates and initializes a `git_diff_parsed` structure. This structure also contains diff options. While we initialize its flags, we fail to do a real initialization of its values. This bites us when we want to actually use the generated diff as we do not se the option's version field, which is required to operate correctly. Fix the issue by executing `git_diff_init_options` on the embedded struct.
Patrick Steinhardt committed -
In a diff, the shortest possible hunk with a modification (that is, no deletion) results from a file with only one line with a single character which is removed. Thus the following hunk @@ -1 +1 @@ -a + is the shortest valid hunk modifying a line. The function parsing the hunk body though assumes that there must always be at least 4 bytes present to make up a valid hunk, which is obviously wrong in this case. The absolute minimum number of bytes required for a modification is actually 2 bytes, that is the "+" and the following newline. Note: if there is no trailing newline, the assumption will not be offended as the diff will have a line "\ No trailing newline" at its end. This patch fixes the issue by lowering the amount of bytes required.
Patrick Steinhardt committed -
The current logic of `git_diff_foreach` makes the assumption that all diffs passed in are actually derived from generated diffs. With these assumptions we try to derive the actual diff by inspecting either the working directory files or blobs of a repository. This obviously cannot work for diffs parsed from a file, where we do not necessarily have a repository at hand. Since the introduced split of parsed and generated patches, there are multiple functions which help us to handle patches generically, being indifferent from where they stem from. Use these functions and remove the old logic specific to generated patches. This allows re-using the same code for invoking the callbacks on the deltas.
Patrick Steinhardt committed
-
- 24 Aug, 2016 1 commit
-
-
Ensure that `git_patch_from_diff` can return the patch for parsed diffs, not just generate a patch for a generated diff.
Edward Thomson committed
-
- 26 Jun, 2016 4 commits
-
-
When showing copy information because we are duplicating contents, for example, when performing a `diff --find-copies-harder -M100 -B100`, then show copy from/to lines in a patch, and do not show context. Ensure that we can also parse such patches.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
Test that we can create a diff file, then parse the results and that the two are identical in-memory.
Edward Thomson committed
-
- 26 May, 2016 1 commit
-
-
Parse diff files into a `git_diff` structure.
Edward Thomson committed
-