summaryrefslogtreecommitdiff
path: root/tests/diff
Commit message (Collapse)AuthorAgeFilesLines
* refactor: `tests` is now `tests/libgit2`Edward Thomson2022-02-2220-11185/+0
| | | | | | Like we want to separate libgit2 and utility source code, we want to separate libgit2 and utility tests. Start by moving all the tests into libgit2.
* diff_file: test empty workdir file grows after obtaining a diffEdward Thomson2022-02-111-1/+28
| | | | | This test was also provided by @jorio https://github.com/libgit2/libgit2/pull/6208#issuecomment-1034072050
* diff_file: test workdir file becomes empty after obtaining a diffIliyas Jorio2022-02-111-0/+29
|
* diff_file: fix crash if size of diffed file changes in workdirIliyas Jorio2022-02-111-0/+77
| | | | | | | | | | | | | "diff_file_content_load_workdir_file()" maps a file from the workdir into memory. It uses git_diff_file.size to determine the size of the memory mapping. If this value goes stale, the mmaped area would be sized incorrectly. This could occur if an external program changes the contents of the file after libgit2 had cached its size. This used to segfault if the file becomes smaller (mmaped area too large). This patch causes diff_file_content_load_workdir_file to fail without crashing if it detects that the file size has changed.
* index: use a byte array for checksumEdward Thomson2022-01-271-6/+9
| | | | | | | | | | | The index's checksum is not an object ID, so we should not use the `git_oid` type. Use a byte array for checksum calculation and storage. Deprecate the `git_index_checksum` function without a replacement. This is an abstraction that callers should not care about (and indeed do not seem to be using). Remove the unused `git_index__changed_relative_to` function.
* Fix typosDimitris Apostolou2022-01-051-1/+1
|
* blob: identify binary contentethomson/blob_data_is_binaryEdward Thomson2021-12-101-0/+16
| | | | | Introduce `git_blob_data_is_binary` to examine a blob's data, instead of the blob itself. A replacement for `git_buf_is_binary`.
* tests: declare functions statically where appropriateEdward Thomson2021-11-113-3/+3
|
* path: separate git-specific path functions from utilEdward Thomson2021-11-092-6/+6
| | | | | | Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-1710-142/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* diff: deprecate diff_format_emailethomson/emailEdward Thomson2021-09-181-0/+20
| | | | `git_diff_format_email` is deprecated in favor of `git_email_create`.
* email: allow `git_diff_commit_as_email` to take 0 as patch indexEdward Thomson2021-09-181-1/+0
| | | | | Allow a `0` patch index and `0` patch count; in this case, simply don't display these in the email.
* Merge branch 'pr/5853'Edward Thomson2021-05-191-0/+35
|\
| * diff: test ignore-blank-linesEdward Thomson2021-05-181-0/+35
| |
* | Add testcaseKartikaya Gupta2021-05-121-0/+55
| |
* | buf: remove internal `git_buf_text` namespaceEdward Thomson2021-05-112-3/+1
|/ | | | | The `git_buf_text` namespace is unnecessary and strange. Remove it, just keep the functions prefixed with `git_buf`.
* Merge pull request #5494 from kevinjswinton/masterEdward Thomson2020-10-042-4/+2
|\ | | | | Fix binary diff showing /dev/null
| * Fix binary diff showing /dev/nullKevin Swinton2020-04-182-4/+2
| | | | | | | | | | | | Fixes issue where a changed binary file's content in the working tree isn't displayed correctly, instead showing an oid of zero, and with its path being reported incorrectly as "/dev/null".
* | Merge pull request #5620 from dlax/parse-patch-add-delete-no-indexEdward Thomson2020-10-041-0/+23
|\ \ | | | | | | patch_parse: handle absence of "index" header for new/deleted cases
| * | patch_parse: handle absence of "index" header for new/deleted casesDenis Laxalde2020-08-291-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This follows up on 11de594f85479e4804b07dc4f7b33cfe9212bea0 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.
* | | diff stats: fix segfaults with new filesDrew DeVault2020-09-161-0/+35
|/ /
* | Merge pull request #5541 from libgit2/ethomson/clar_tapEdward Thomson2020-06-052-14/+15
|\ \ | | | | | | clar: add tap output option
| * | clar: include the function nameethomson/clar_tapEdward Thomson2020-06-052-14/+15
| | |
* | | diff::parse: don't include `diff.h`ethomson/diff_parseEdward Thomson2020-06-051-1/+0
|/ / | | | | | | | | We don't call any internal functions in the test; we don't need to include `../src/diff.h`.
* | diff::workdir: actually test the buffersethomson/difftestEdward Thomson2020-05-231-3/+3
|/ | | | | | The static test data is erroneously initialized with a length of 0 for three of the strings. This means the tests are not actually examining those strings. Provide the length.
* tests: diff: add test to verify behaviour with empty dir orderingPatrick Steinhardt2020-02-071-0/+43
| | | | | | | It was reported that, given a file "abc.txt", a diff will be shown if an empty directory "abb/" is created, but not if "abd/" is created. Add a test to verify that we do the right thing here and do not depend on any ordering.
* tests: diff: verify that we are able to diff with empty subtreesPatrick Steinhardt2020-02-071-0/+49
| | | | | | | | | | | | While it is not allowed for a tree to have an empty tree as child (e.g. an empty directory), libgit2's tree builder makes it easy to create such trees. As a result, some applications may inadvertently end up with such an invalid tree, and we should try our best and handle them. One such case is when diffing two trees, where one of both trees has such an empty subtree. It was reported that this will cause our diff code to fail. While I wasn't able to reproduce this error, let's still add a test that verifies we continue to handle them correctly.
* diff: make patchid computation work with all types of commits.Gregory Herrero2019-11-281-0/+33
| | | | | | | | | | Current implementation of patchid is not computing a correct patchid when given a patch where, for example, a new file is added or removed. Some more corner cases need to be handled to have same behavior as git patch-id command. Add some more tests to cover those corner cases. Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
* patch_parse: handle patches without extended headersDenis Laxalde2019-10-161-0/+10
| | | | | | | | | 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.
* patch_parse: handle patches with new empty filesDenis Laxalde2019-09-281-0/+20
| | | | | | | 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 cc4c44a and allow "-- " to immediately follow the index header.
* 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.
* configuration: cvar -> configmapPatrick Steinhardt2019-07-181-1/+1
| | | | | `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
* oid: `is_zero` instead of `iszero`Edward Thomson2019-06-161-10/+10
| | | | | | The only function that is named `issomething` (without underscore) was `git_oid_iszero`. Rename it to `git_oid_is_zero` for consistency with the rest of the library.
* Rename opt init functions to `options_init`Edward Thomson2019-06-143-4/+4
| | | | | | | | | | | | | In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.
* patch_parse.c: Handle CRLF in parse_header_startDrew DeVault2019-04-051-0/+19
|
* tests: diff: test parsing diffs with a new file with spaces in its pathErik Aigner2019-03-291-0/+18
| | | | | Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-227-29/+29
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-013-4/+4
| | | | Use the new object_type enumeration names within the codebase.
* index: use new enum and structure namesEdward Thomson2018-12-011-3/+3
| | | | Use the new-style index names throughout our own codebase.
* diff_stats: use git's formatting of renames with common directoriesPatrick Steinhardt2018-10-041-1/+1
| | | | | | | | | | | In cases where a file gets renamed such that the directories containing it previous and after the rename have a common prefix, then git will avoid printing this prefix twice and instead format the rename as "prefix/{old => new}". We currently didn't do anything like that, but simply printed "prefix/old -> prefix/new". Adjust our behaviour to instead match upstream. Adjust the test for this behaviour to expect the new format.
* tests: verify diff stats with renames in subdirectoryPatrick Steinhardt2018-10-041-0/+19
| | | | | | | | | | | Until now, we didn't have any tests that verified that our format for renames in subdirectories is correct. While our current behaviour is no different than for renames that do not happen with a common prefix shared between old and new file name, we intend to change the format to instead match the format that upstream git uses. Add a test case for this to document our current behaviour and to show how the next commit will change that format.
* Merge pull request #4702 from tiennou/fix/coverityPatrick Steinhardt2018-07-201-2/+2
|\ | | | | Assorted Coverity fixes
| * tests: add missing cl_git_pass to testsEtienne Samson2018-07-061-2/+2
| | | | | | Reported by Coverity, CID 1393678-1393697.
* | Merge pull request #4719 from pks-t/pks/delta-oobEdward Thomson2018-07-091-0/+1
|\ \ | |/ |/| Delta OOB access
| * delta: fix sign-extension of big left-shiftPatrick Steinhardt2018-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our delta code was originally adapted from JGit, which itself adapted it from git itself. Due to this heritage, we inherited a bug from git.git in how we compute the delta offset, which was fixed upstream in 48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As explained by Linus: Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. In our delta code, we inherited such a bogus shift when computing the offset at which the delta base is to be found. Due to the sign extension we can end up with an offset where all the bits are set. This can allow an arbitrary memory read, as the addition in `base_len < off + len` can now overflow if `off` has all its bits set. Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned integer again. Add a test with a crafted delta that would actually succeed with an out-of-bounds read in case where the cast wouldn't exist. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
* | patch_parse: populate line numbers while parsing diffsEtienne Samson2018-06-191-0/+71
|/
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-1011-77/+77
|
* Sanitize the hunk header to ensure it contains UTF-8 valid dataStan Hu2018-05-051-0/+92
| | | | | | | | | | The diff driver truncates the hunk header text to 80 bytes, which can truncate 4-byte Unicode characters and introduce garbage characters in the diff output. This change sanitizes the hunk header before it is displayed. This mirrors the test in git: https://github.com/git/git/blob/master/t/t4025-hunk-header.sh Closes https://github.com/libgit2/rugged/issues/716
* typo: Fixed a trivial typo in test function.Erik van Zijst2018-04-051-1/+1
|
* diff_tform: fix rename detection with rewrite/delete pairPatrick Steinhardt2018-02-201-0/+213
| | | | | | | | | | | | | | | | | | | | | A rewritten file can either be classified as a modification of its contents or of a delete of the complete file followed by an addition of the new content. This distinction becomes important when we want to detect renames for rewrites. Given a scenario where a file "a" has been deleted and another file "b" has been renamed to "a", this should be detected as a deletion of "a" followed by a rename of "a" -> "b". Thus, splitting of the original rewrite into a delete/add pair is important here. This splitting is represented by a flag we can set at the current delta. While the flag is already being set in case we want to break rewrites, we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` flag is set. This can trigger an assert when we try to match the source and target deltas. Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is set.
View Lorry Controller Status