- 12 Feb, 2022 3 commits
-
-
This test was also provided by @jorio https://github.com/libgit2/libgit2/pull/6208#issuecomment-1034072050
Edward Thomson committed -
Iliyas Jorio committed
-
"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.
Iliyas Jorio committed
-
- 28 Jan, 2022 1 commit
-
-
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.
Edward Thomson committed
-
- 05 Jan, 2022 1 commit
-
-
Dimitris Apostolou committed
-
- 10 Dec, 2021 1 commit
-
-
Introduce `git_blob_data_is_binary` to examine a blob's data, instead of the blob itself. A replacement for `git_buf_is_binary`.
Edward Thomson committed
-
- 11 Nov, 2021 1 commit
-
-
Edward Thomson committed
-
- 09 Nov, 2021 1 commit
-
-
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).
Edward Thomson committed
-
- 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
-
- 18 Sep, 2021 2 commits
-
-
`git_diff_format_email` is deprecated in favor of `git_email_create`.
Edward Thomson committed -
Allow a `0` patch index and `0` patch count; in this case, simply don't display these in the email.
Edward Thomson committed
-
- 18 May, 2021 1 commit
-
-
Edward Thomson committed
-
- 13 May, 2021 1 commit
-
-
Kartikaya Gupta committed
-
- 11 May, 2021 1 commit
-
-
The `git_buf_text` namespace is unnecessary and strange. Remove it, just keep the functions prefixed with `git_buf`.
Edward Thomson committed
-
- 16 Sep, 2020 1 commit
-
-
Drew DeVault 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
-
- 23 May, 2020 1 commit
-
-
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.
Edward Thomson committed
-
- 18 Apr, 2020 1 commit
-
-
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".
Kevin Swinton committed
-
- 07 Feb, 2020 2 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed
-
- 28 Nov, 2019 1 commit
-
-
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>
Gregory Herrero 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
-
- 20 Jul, 2019 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 18 Jul, 2019 1 commit
-
-
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
Patrick Steinhardt committed
-
- 15 Jun, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 14 Jun, 2019 1 commit
-
-
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.
Edward Thomson 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
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 01 Dec, 2018 2 commits
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed -
Use the new-style index names throughout our own codebase.
Edward Thomson committed
-
- 04 Oct, 2018 2 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed
-
- 06 Jul, 2018 1 commit
-
-
Reported by Coverity, CID 1393678-1393697.
Etienne Samson committed
-
- 29 Jun, 2018 1 commit
-
-
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>
Patrick Steinhardt committed
-
- 18 Jun, 2018 1 commit
-
-
Etienne Samson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-