kmx git

Commit	Date	Message
786b29cb	2020-03-08T02:13:11	Fix segfault when calling git_blame_buffer() This change makes sure that the hunk is not null before trying to dereference it. This avoids segfaults, especially when blaming against a modified buffer (i.e. the index). Fixes: #5443
aeda6786	2020-01-15T13:31:21	refs: refuse to delete HEAD This requires adding a new symbolic ref to the testrepo fixture. Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead. Adjust a few other tests as needed. Fixes #5357
60d1f99e	2019-11-28T15:26:36	patch_parse: fix out-of-bounds reads caused by integer underflow The patch format for binary files is a simple Base85 encoding with a length byte as prefix that encodes the current line's length. For each line, we thus check whether the line's actual length matches its expected length in order to not faultily apply a truncated patch. This also acts as a check to verify that we're not reading outside of the line's string: if (encoded_len > ctx->parse_ctx.line_len - 1) { error = git_parse_err(...); goto done; } There is the possibility for an integer underflow, though. Given a line with a single prefix byte, only, `line_len` will be zero when reaching this check. As a result, subtracting one from that will result in an integer underflow, causing us to assume that there's a wealth of bytes available later on. Naturally, this may result in an out-of-bounds read. Fix the issue by checking both `encoded_len` and `line_len` for a non-zero value. The binary format doesn't make use of zero-length lines anyway, so we need to know that there are both encoded bytes and remaining characters available at all. This patch also adds a test that works based on the last error message. Checking error messages is usually too tightly coupled, but in fact parsing the patch failed even before the change. Thus the only possibility is to use e.g. Valgrind, but that'd result in us not catching issues when run without Valgrind. As a result, using the error message is considered a viable tradeoff as we know that we didn't start decoding Base85 in the first place.
8ff44c2a	2019-11-10T18:44:56	patch_parse: use paths from "---"/"+++" lines for binary patches For some patches, it is not possible to derive the old and new file paths from the patch header's first line, most importantly when they contain spaces. In such a case, we derive both paths from the "---" and "+++" lines, which allow for non-ambiguous parsing. We fail to use these paths when parsing binary patches without data, though, as we always expect the header paths to be filled in. Fix this by using the "---"/"+++" paths by default and only fall back to header paths if they aren't set. If neither of those paths are set, we just return an error. Add two tests to verify this behaviour, one of which would have previously caused a segfault.
7ce231ff	2019-11-05T22:44:27	patch_parse: fix segfault when header path contains whitespace only When parsing header paths from a patch, we reject any patches with empty paths as malformed patches. We perform the check whether a path is empty before sanitizing it, though, which may lead to a path becoming empty after the check, e.g. if we have trimmed whitespace. This may lead to a segfault later when any part of our patching logic actually references such a path, which may then be a `NULL` pointer. Fix the issue by performing the check after sanitizing. Add tests to catch the issue as they would have produced a segfault previosuly.
54f0a278	2019-10-21T18:56:59	patch_parse: detect overflow when calculating old/new line position When the patch contains lines close to INT_MAX, then it may happen that we end up with an integer overflow when calculating the line of the current diff hunk. Reject such patches as unreasonable to avoid the integer overflow. As the calculation is performed on integers, we introduce two new helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform the integer overflow check in a generic way.
608cb07d	2019-10-19T16:48:11	patch_parse: fix out-of-bounds read with No-NL lines We've got two locations where we copy lines into the patch. The first one is when copying normal " ", "-" or "+" lines, while the second location gets executed when we copy "\ No newline at end of file" lines. While the first one correctly uses `git__strndup` to copy only until the newline, the other one doesn't. Thus, if the line occurs at the end of the patch and if there is no terminating NUL character, then it may result in an out-of-bounds read. Fix the issue by using `git__strndup`, as was already done in the other location. Furthermore, add allocation checks to both locations to detect out-of-memory situations.
3223f5de	2019-10-19T15:52:35	patch_parse: reject empty path names When parsing patch headers, we currently accept empty path names just fine, e.g. a line "--- \n" would be parsed as the empty filename. This is not a valid patch format and may cause `NULL` pointer accesses at a later place as `git_buf_detach` will return `NULL` in that case. Reject such patches as malformed with a nice error message.
db73191b	2019-10-19T15:42:54	patch_parse: reject patches with multiple old/new paths It's currently possible to have patches with multiple old path name headers. As we didn't check for this case, this resulted in a memory leak when overwriting the old old path with the new old path because we simply discarded the old pointer. Instead of fixing this by free'ing the old pointer, we should reject such patches altogether. It doesn't make any sense for the "---" or "+++" markers to occur multiple times within a patch n the first place. This also implicitly fixes the memory leak.
fc60777e	2019-10-16T22:11:33	patch_parse: handle patches without extended headers 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.
fceedda5	2019-10-11T12:44:09	refs: unlock unmodified refs on transaction commit Refs which are locked in a transaction without an altered target, still should to be unlocked on `git_transaction_commit`. `git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free` cannot be controlled in all situations. Some binding libs call `git_transaction_free` on garbage collection or not at all if the application exits before and don't provide public access to `git_transaction_free`. It is better to release locks as soon as possible.
5aca2444	2019-10-10T15:28:46	refs: fix locks getting forcibly removed The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.
85ab27c8	2019-09-28T15:52:25	patch_parse: handle patches with new empty files 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.
3c605da6	2019-09-19T12:24:06	buffer: fix printing into out-of-memory buffer Before printing into a `git_buf` structure, we always call `ENSURE_SIZE` first. This macro will reallocate the buffer as-needed depending on whether the current amount of allocated bytes is sufficient or not. If `asize` is big enough, then it will just do nothing, otherwise it will call out to `git_buf_try_grow`. But in fact, it is insufficient to only check `asize`. When we fail to allocate any more bytes e.g. via `git_buf_try_grow`, then we set the buffer's pointer to `git_buf__oom`. Note that we touch neither `asize` nor `size`. So if we just check `asize > targetsize`, then we will happily let the caller of `ENSURE_SIZE` proceed with an out-of-memory buffer. As a result, we will print all bytes into the out-of-memory buffer instead, resulting in an out-of-bounds write. Fix the issue by having `ENSURE_SIZE` verify that the buffer is not marked as OOM. Add a test to verify that we're not writing into the OOM buffer.
93dc8a04	2019-09-19T12:46:37	buffer: fix infinite loop when growing buffers When growing buffers, we repeatedly multiply the currently allocated number of bytes by 1.5 until it exceeds the requested number of bytes. This has two major problems: 1. If the current number of bytes is tiny and one wishes to resize to a comparatively huge number of bytes, then we may need to loop thousands of times. 2. If resizing to a value close to `SIZE_MAX` (which would fail anyway), then we probably hit an infinite loop as multiplying the current amount of bytes will repeatedly result in integer overflows. When reallocating buffers, one typically chooses values close to 1.5 to enable re-use of resulting memory holes in later reallocations. But because of this, it really only makes sense to use a factor of 1.5 _once_, but not looping until we finally are able to fit it. Thus, we can completely avoid the loop and just opt for the much simpler algorithm of multiplying with 1.5 once and, if the result doesn't fit, just use the target size. This avoids both problems of looping extensively and hitting overflows. This commit also adds a test that would've previously resulted in an infinite loop.
8c99ccc5	2019-09-10T11:14:36	open:fix memory leak when passing NULL to git_repository_open_ext
99b89a9c	2019-08-24T12:14:31	ignore: correct handling of nested rules overriding wild card unignore problem: filesystem_iterator loads .gitignore files in top-down order. subsequently, ignore module evaluates them in the order they are loaded. this creates a problem if we have unignored a rule (using a wild card) in a sub dir and ignored it again in a level further below (see the test included in this patch). solution: process ignores in reverse order. closes #4963
5e5a9cce	2019-08-28T23:18:31	apply: Test for EOFNL mishandling when several hunks are processed Introduce an unit test to validate that git_apply__patch() properly handles EOFNL changes in case of patches with several hunks.
ae9b333a	2019-08-27T13:10:53	apply: free test data
deda897a	2019-08-21T15:03:50	apply: Test for git_apply_to_tree failures when new files are added Introduce an unit test to validate if git_apply_to_tree() fails when an applied patch adds new files.
16dbedc9	2019-07-11T12:12:04	patch_parse: ensure valid patch output with EOFNL
fe012c60	2019-07-05T11:06:33	patch_parse: handle missing newline indicator in old file When either the old or new file contents have no newline at the end of the file, then git-diff(1) will print out a "\ No newline at end of file" indicator. While we do correctly handle this in the case where the new file has this indcator, we fail to parse patches where the old file is missing a newline at EOF. Fix this bug by handling and missing newline indicators in the old file. Add tests to verify that we can parse such files.
782bc334	2019-07-05T09:35:43	patch_parse: do not depend on parsed buffer's lifetime When parsing a patch from a buffer, we let the patch lines point into the original buffer. While this is efficient use of resources, this also ties the lifetime of the parsed patch to the parsed buffer. As this behaviour is not documented anywhere in our API it is very surprising to its users. Untie the lifetime by duplicating the lines into the parsed patch. Add a test that verifies that lifetimes are indeed independent of each other.
2ce6eddf	2019-02-21T08:30:22	tests: apply: verify that we correctly truncate the source buffer Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.
a673ce14	2019-12-03T23:15:47	path: support non-ascii drive letters on dos Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.
6bd07401	2019-12-03T19:50:18	index: ensure that we respect core.protectNTFS=false Users may want to turn off core.protectNTFS, perhaps to import (and then repair) a broken tree. Ensure that core.protectNTFS=false is honored.
0d8b9373	2019-12-03T23:23:02	tree: ensure we protect NTFS paths everywhere
50a33c30	2019-12-03T19:24:59	path: protect NTFS everywhere Enable core.protectNTFS by default everywhere and in every codepath, not just on checkout.
aa0902f4	2019-12-03T19:17:41	test: ensure we can't add a protected path Test that when we enable core.protectNTFS that we cannot add platform-specific invalid paths to the index.
f26b03d9	2019-12-03T19:01:00	test: improve badname verification test The name of the `add_invalid_filename` function suggests that we _want_ to add an invalid filename. Rename the function to show that we expect to _fail_ to add the invalid filename.
94589e7c	2019-12-03T18:57:16	test: ensure treebuilder validate new protection rules Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for using the treebuilder when core.protectNTFS is set.
fd255d2c	2019-12-03T18:56:31	test: ensure index adds validate new protection rules Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for adding to the index when core.protectNTFS is set.
a336ed18	2019-12-03T18:49:23	test: improve badname verification test The name of the `write_invalid_filename` function suggests that we _want_ to write an invalid filename. Rename the function to show that we expect to _fail_ to write the invalid filename.
ac0b2ef1	2019-09-18T16:33:18	path: also guard `.gitmodules` against NTFS Alternate Data Streams We just safe-guarded `.git` against NTFS Alternate Data Stream-related attack vectors, and now it is time to do the same for `.gitmodules`. Note: In the added regression test, we refrain from verifying all kinds of variations between short names and NTFS Alternate Data Streams: as the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it is enough to test one in order to know that all of them are guarded against. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
460a9fdc	2019-09-18T14:32:05	Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS A little-known feature of NTFS is that it offers to store metadata in so-called "Alternate Data Streams" (inspired by Apple's "resource forks") that are copied together with the file they are associated with. These Alternate Data Streams can be accessed via `<file name>:<stream name>:<stream type>`. Directories, too, have Alternate Data Streams, and they even have a default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and `abc::$INDEX_ALLOCATION/` are actually equivalent. This is of course another attack vector on the Git directory that we definitely want to prevent. On Windows, we already do this incidentally, by disallowing colons in file/directory names. While it looks as if files'/directories' Alternate Data Streams are not accessible in the Windows Subsystem for Linux, and neither via CIFS/SMB-mounted network shares in Linux, it _is_ possible to access them on SMB-mounted network shares on macOS. Therefore, let's go the extra mile and prevent this particular attack _everywhere_. To keep things simple, let's just disallow any Alternate Data Stream of `.git`. This is libgit2's variant of CVE-2019-1352. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
7bf80ab0	2019-09-18T15:25:02	Protect against 8.3 "short name" attacks also on Linux/macOS The Windows Subsystem for Linux (WSL) is getting increasingly popular, in particular because it makes it _so_ easy to run Linux software on Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to `/mnt/c/`, no need to set that up manually). Unfortunately, files/directories on the Windows drives can be accessed via their _short names_, if that feature is enabled (which it is on the `C:` drive by default). Which means that we have to safeguard even our Linux users against the short name attacks. Further, while the default options of CIFS/SMB-mounts seem to disallow accessing files on network shares via their short names on Linux/macOS, it _is_ possible to do so with the right options. So let's just safe-guard against short name attacks _everywhere_. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
48043516	2019-09-18T15:08:56	cl_git_fail: do not report bogus error message When we expect a checkout operation to fail, but it succeeds, we actually do not want to see the error messages that were generated in the meantime for errors that were handled gracefully by the code (e.g. when an object could not be found in a pack: in this case, the next backend would have been given a chance to look up the object, and probably would have found it because the checkout succeeded, after all). Which means that in the specific case of `cl_git_fail()`, we actually want to clear the global error state _after_ evaluating the command: we know that any still-available error would be bogus, seeing as the command succeeded (unexpectedly). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
98c11905	2019-03-20T12:28:45	Correctly write to missing locked global config Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string. (cherry picked from commit e44110dbbfc9d50b883d73fbb6c9e3b53732ec9d)
9b698978	2019-04-12T08:54:06	git_repository_init: stop traversing at windows root Stop traversing the filesystem at the Windows directory root. We were calculating the filesystem root for the given directory to create, and walking up the filesystem hierarchy. We intended to stop when the traversal path length is equal to the root path length (ie, stopping at the root, since no path may be shorter than the root path). However, on Windows, the root path may be specified in two different ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter. `git_path_dirname_r` returns the path _without_ a trailing slash, even for the Windows root. As a result, during traversal, we need to test that the traversal path is _less than or equal to_ the root path length to determine if we've hit the root to ensure that we stop when our traversal path is `Z:` and our calculated root path was `Z:\`.
21baf7ab	2019-04-05T10:22:46	ignore: treat paths with trailing "/" as directories The function `git_ignore_path_is_ignored` is there to test the ignore status of paths that need not necessarily exist inside of a repository. This has the implication that for a given path, we cannot always decide whether it references a directory or a file, and we need to distinguish those cases because ignore rules may treat those differently. E.g. given the following gitignore file: * !/**/ we'd only want to unignore directories, while keeping files ignored. But still, calling `git_ignore_path_is_ignored("dir/")` will say that this directory is ignored because it treats "dir/" as a file path. As said, the `is_ignored` function cannot always decide whether the given path is a file or directory, and thus it may produce wrong results in some cases. While this is unfixable in the general case, we can do better when we are being passed a path name with a trailing path separator (e.g. "dir/") and always treat them as directories.
71424f63	2019-03-22T23:56:10	patch_parse.c: Handle CRLF in parse_header_start
4ec209cd	2019-03-29T12:30:37	tests: diff: test parsing diffs with a new file with spaces in its path Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
1df7d27a	2019-03-20T13:24:07	ignore: move tests from status to attr ignore suite
93971ca6	2019-03-15T13:08:18	ignore: add additional test cases
12bc7181	2019-03-14T15:51:15	ignore: Do not match on prefix of negated patterns Matching on the prefix of a negated pattern was triggering false negatives on siblings of that pattern. e.g. Given the .gitignore: dir/* !dir/sub1/sub2/** The path `dir/a.text` would not be ignored.
aa877e09	2019-03-14T09:59:27	Implement failing test for gitignore of complex subdirectory negation When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored
5189beb0	2019-02-16T19:55:30	Fix a memory leak in odb_otype_fast() This change frees a copy of a cached object in odb_otype_fast().
24ac9e0c	2019-02-13T23:26:54	deprecation: ensure we GIT_EXTERN deprecated funcs Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples.
3fba5891	2019-01-20T23:53:33	test: cast to a char the zstream test
f25bb508	2019-01-20T23:52:50	index test: cast times explicitly Cast actual filesystem data to the int32_t that index entries store.
826d9a4d	2019-01-25T09:43:20	Merge pull request #4858 from tiennou/fix/index-ext-read index: preserve extension parsing errors
c951b825	2019-01-23T00:32:40	deprecation: define GIT_DEPRECATE_HARD internally Ensure that we do not use any deprecated functions in the library source, test code or examples.
9c5e05ad	2019-01-23T10:43:29	deprecation: move deprecated tests into their own file Move the deprecated stream tests into their own compilation unit. This will allow us to disable any preprocessor directives that apply to deprecation just for these tests (eg, disabling `GIT_DEPRECATED_HARD`).
0bf7e043	2019-01-24T12:12:04	index: preserve extension parsing errors Previously, we would clobber any extension-specific error message with an "extension is truncated" message. This makes `read_extension` correctly preserve those errors, takes responsibility for truncation errors, and adds a new message with the actual extension signature for unsupported mandatory extensions.
f673e232	2018-12-27T13:47:34	git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
f7416509	2019-01-20T20:15:31	Fix odb foreach to also close on positive error code In include/git2/odb.h it states that callback can also return positive value which should break looping. Implementations of git_odb_foreach() and pack_backend__foreach() did not respect that.
1758636b	2019-01-19T01:38:34	Merge pull request #4939 from libgit2/ethomson/git_ref Move `git_ref_t` to `git_reference_t`
b2c2dc64	2019-01-19T01:36:40	Merge pull request #4940 from libgit2/ethomson/git_obj More `git_obj` to `git_object` updates
c352e561	2019-01-19T01:34:21	Merge pull request #4943 from libgit2/ethomson/ci ci: only run invasive tests in nightly
423d3e73	2019-01-19T00:08:05	ci: precisely identify the invasive tests
abe23675	2019-01-17T20:09:05	Merge pull request #4925 from lhchavez/fix-a-bunch-of-warnings Fix a bunch of warnings
cd350852	2019-01-17T10:40:13	object_type: GIT_OBJECT_BAD is now GIT_OBJECT_INVALID We use the term "invalid" to refer to bad or malformed data, eg `GIT_REF_INVALID` and `GIT_EINVALIDSPEC`. Since we're changing the names of the `git_object_t`s in this release, update it to be `GIT_OBJECT_INVALID` instead of `BAD`.
ed8cfbf0	2019-01-17T00:32:31	references: use new names in internal usage Update internal usage to use the `git_reference` names for constants.
7a43a892	2019-01-15T00:42:14	Convert tests/resources/push.sh to LF endings This changes that file to use UNIX line-endings, which makes sense since this is a UNIXy file.
a653f967	2019-01-14T16:08:05	Get rid of some test files that were accidentally committed
35d86c77	2019-01-14T10:14:36	proxy: fix crash on remote connection with GIT_PROXY_AUTO but no proxy is detected
54ae0528	2019-01-14T01:25:05	tests: fix test expectation mismatch
1b4ba844	2019-01-11T11:53:54	ci: enable some of the invasive testcases
8b599528	2019-01-08T17:26:14	Fix Linux warnings This change fixes -Wmaybe-uninitialized and -Wdeprecated-declarations warnings on Linux builds
321d19c1	2019-01-06T08:36:06	Windows is hard.
b5e8272f	2019-01-06T08:29:56	Attempt at fixing the MingW64 compilation It seems like MingW64's size_t is defined differently than in Linux.
7b453e7e	2019-01-05T22:12:48	Fix a bunch of warnings This change fixes a bunch of warnings that were discovered by compiling with `clang -target=i386-pc-linux-gnu`. It turned out that the intrinsics were not necessarily being used in all platforms! Especially in GCC, since it does not support __has_builtin. Some more warnings were gleaned from the Windows build, but I stopped when I saw that some third-party dependencies (e.g. zlib) have warnings of their own, so we might never be able to enable -Werror there.
50d4688c	2019-01-04T13:41:50	tests: add missing asserts CID 1398597, 1398598
9084712b	2019-01-03T12:01:52	Merge pull request #4904 from libgit2/ethomson/crlf Update CRLF filtering to match modern git
e385e647	2018-12-19T12:08:17	checkout::crlf: ensure success Wrap function calls in the `checkout::crlf` tests with `cl_git_pass`, `cl_assert`, etc. to ensure that they're successful.
bc219657	2018-12-19T11:01:55	Merge pull request #4833 from csware/drop-empty-dirs Remove empty (sub-)directories when deleting refs
0f299365	2018-12-14T14:29:36	annotated_commit: add failing test for looking up from annotated tag
2a9b0102	2015-01-23T14:16:34	Additional core.autocrlf and core.safecrlf tests This is a cherry-pick of the tests from the following commits: core.autocrlf=true and core.safecrlf=true did not fail on LF-only file as vanilla git does Adding a CRLF-file with core.autocrlf=input and core.safecrlf=true does not fail as with vanilla git Make files with #CR!=#CRLF not fail with core.safecrlf=true Reported-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Signed-off-by: Sven Strickroth <email@cs-ware.de>
59b054cb	2018-12-03T13:54:32	index::crlf: better error reporting in core git tests Don't simply fail when the expected output does not match the data in the index; instead, provide a detailed output about the system, file, and settings that caused the failure so that developers can better isolate the problem(s).
021a08b0	2018-12-01T22:33:16	index::crlf: simplify test case
e417fd99	2015-07-01T17:00:16	crlf tests: use known-good data produced by git Given a variety of combinations of core.autocrlf, core.safecrlf settings and attributes settings, test that we add files to index the same way (regarding OIDs and fatal errors) as a known-good test resource created by git.git. Signed-off-by: Sven Strickroth <email@cs-ware.de>
3d804063	2018-12-01T21:46:51	crlf_data: add corpus of known-good odb-filtered data Use the crlf data scripts to produce a corpus of known-good data in "git" format (aka ODB format) from a variety of files with different line endings. `git` created these files running `git add` to stage the contents then extracting the data from the repository. We'll use these to ensure that we create identical contents when we add files into the index.
a0ab90b8	2018-12-01T21:53:07	crlf: re-use existing crlf script to create odb Re-use the existing crlf data generation script for creating the to-odb dataset. Also, store the actual file contents instead of the ID so that we can identify differences instead of detecting that differences exist.
9065160b	2015-07-01T16:55:06	crlf: script to generate expected crlf data for adding files to index Include a shell script that will generate the expected data of OIDs and failures for calling git.git to capture its output as a test resource. Right now, there is no need to differentiate different systems as git behaves the same on all systems IIRC. Signed-off-by: Sven Strickroth <email@cs-ware.de>
c3169e6f	2018-12-01T19:59:41	checkout::crlf clear the crlf workdir for checkout After sandboxing the crlf directory, remove the working directory contents. This allows us to package data within the crlf directory (for simplicity, this allows us to script the to-odb and to-workdir crlf filter conversion data in a single location).
13a8bc92	2018-12-01T18:32:01	crlf_data: move to a "to_workdir" folder Move the crlf_data folders reponsible for holding the state of the filters going into the working directory to "to_workdir" variations of the folder name to accommodate future growth into the "to odb" filter variation. Update the script to create these new folders as appopriate.
168fe39b	2018-11-28T14:26:57	object_type: use new enumeration names Use the new object_type enumeration names within the codebase.
18e71e6d	2018-11-28T13:31:06	index: use new enum and structure names Use the new-style index names throughout our own codebase.
0ddc6094	2018-11-30T09:46:14	Merge pull request #4770 from tiennou/feature/merge-analysis-any-branch Allow merge analysis against any reference
e7873eb2	2018-11-29T08:00:31	Merge pull request #4888 from TheBB/add-cb revwalk: Allow changing hide_cb
487233fa	2018-11-29T07:21:41	Merge pull request #4895 from pks-t/pks/unused-warnings Unused function warnings
a904fc6d	2018-11-28T20:31:30	Merge pull request #4870 from libgit2/ethomson/proxy Add builtin proxy support for the http transport
02bb39f4	2018-11-22T08:49:09	stream registration: take an enum type Accept an enum (`git_stream_t`) during custom stream registration that indicates whether the registration structure should be used for standard (non-TLS) streams or TLS streams.
df2cc108	2018-11-18T10:29:07	stream: provide generic registration API Update the new stream registration API to be `git_stream_register` which takes a registration structure and a TLS boolean. This allows callers to register non-TLS streams as well as TLS streams. Provide `git_stream_register_tls` that takes just the init callback for backward compatibliity.
45054732	2018-10-29T10:45:59	tests: optionally ignore https cert validation For testing, we may wish to use a man-in-the-middle proxy that can inspect the CONNECT traffic to our test endpoints. For this, we will need to accept the proxy's certificate, which will not be valid for the true endpoint. Add a new environment variable, GITTEST_REMOTE_SSL_NOVERIFY to disable https certificate validation for the tests.
43b592ac	2018-10-25T08:49:01	tls: introduce a wrap function Introduce `git_tls_stream_wrap` which will take an existing `stream` with an already connected socket and begin speaking TLS on top of it. This is useful if you've built a connection to a proxy server and you wish to begin CONNECT over it to tunnel a TLS connection. Also update the pluggable TLS stream layer so that it can accept a registration structure that provides an `init` and `wrap` function, instead of a single initialization function.
6ba3e6af	2018-11-18T21:53:48	proxy tests: rename credential callback Rename credential callback to proxy_cred_cb to match new cert callback.
394ae7e1	2018-10-22T17:35:35	proxy tests: support self-signed proxy cert Give the proxy tests a proxy certificate callback, and allow self-signed certificates when the `GITTEST_REMOTE_PROXY_SELFSIGNED` environment variable is set (to anything). In that case, simply compare the hostname from the callback to the hostname that we connected to.
4ecc14cd	2018-10-21T23:47:53	tests: support optional PROXY_SCHEME As we want to support HTTPS proxies, support an optional `GITTEST_REMOTE_PROXY_SCHEME` environment variable for tests that will allow for HTTPS support. (When unset, the tests default to HTTP proxies.)
de60d9b4	2018-10-21T21:00:37	tests: PROXY_URL is more accurately PROXY_HOST Change the `GITTEST_REMOTE_PROXY_URL` environment variable to be `GITTEST_REMOTE_PROXY_HOST`, since it is a host:port combination, not an actual URL. (We cannot use a URL here since we may want to include the username:password combination in the constructed URL.)

786b29cb

2020-03-08T02:13:11

Fix segfault when calling git_blame_buffer() This change makes sure that the hunk is not null before trying to dereference it. This avoids segfaults, especially when blaming against a modified buffer (i.e. the index). Fixes: #5443

aeda6786

2020-01-15T13:31:21

refs: refuse to delete HEAD This requires adding a new symbolic ref to the testrepo fixture. Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead. Adjust a few other tests as needed. Fixes #5357

60d1f99e

2019-11-28T15:26:36

patch_parse: fix out-of-bounds reads caused by integer underflow The patch format for binary files is a simple Base85 encoding with a length byte as prefix that encodes the current line's length. For each line, we thus check whether the line's actual length matches its expected length in order to not faultily apply a truncated patch. This also acts as a check to verify that we're not reading outside of the line's string: if (encoded_len > ctx->parse_ctx.line_len - 1) { error = git_parse_err(...); goto done; } There is the possibility for an integer underflow, though. Given a line with a single prefix byte, only, `line_len` will be zero when reaching this check. As a result, subtracting one from that will result in an integer underflow, causing us to assume that there's a wealth of bytes available later on. Naturally, this may result in an out-of-bounds read. Fix the issue by checking both `encoded_len` and `line_len` for a non-zero value. The binary format doesn't make use of zero-length lines anyway, so we need to know that there are both encoded bytes and remaining characters available at all. This patch also adds a test that works based on the last error message. Checking error messages is usually too tightly coupled, but in fact parsing the patch failed even before the change. Thus the only possibility is to use e.g. Valgrind, but that'd result in us not catching issues when run without Valgrind. As a result, using the error message is considered a viable tradeoff as we know that we didn't start decoding Base85 in the first place.

8ff44c2a

2019-11-10T18:44:56

patch_parse: use paths from "---"/"+++" lines for binary patches For some patches, it is not possible to derive the old and new file paths from the patch header's first line, most importantly when they contain spaces. In such a case, we derive both paths from the "---" and "+++" lines, which allow for non-ambiguous parsing. We fail to use these paths when parsing binary patches without data, though, as we always expect the header paths to be filled in. Fix this by using the "---"/"+++" paths by default and only fall back to header paths if they aren't set. If neither of those paths are set, we just return an error. Add two tests to verify this behaviour, one of which would have previously caused a segfault.

7ce231ff

2019-11-05T22:44:27

patch_parse: fix segfault when header path contains whitespace only When parsing header paths from a patch, we reject any patches with empty paths as malformed patches. We perform the check whether a path is empty before sanitizing it, though, which may lead to a path becoming empty after the check, e.g. if we have trimmed whitespace. This may lead to a segfault later when any part of our patching logic actually references such a path, which may then be a `NULL` pointer. Fix the issue by performing the check after sanitizing. Add tests to catch the issue as they would have produced a segfault previosuly.

54f0a278

2019-10-21T18:56:59

patch_parse: detect overflow when calculating old/new line position When the patch contains lines close to INT_MAX, then it may happen that we end up with an integer overflow when calculating the line of the current diff hunk. Reject such patches as unreasonable to avoid the integer overflow. As the calculation is performed on integers, we introduce two new helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform the integer overflow check in a generic way.

608cb07d

2019-10-19T16:48:11

patch_parse: fix out-of-bounds read with No-NL lines We've got two locations where we copy lines into the patch. The first one is when copying normal " ", "-" or "+" lines, while the second location gets executed when we copy "\ No newline at end of file" lines. While the first one correctly uses `git__strndup` to copy only until the newline, the other one doesn't. Thus, if the line occurs at the end of the patch and if there is no terminating NUL character, then it may result in an out-of-bounds read. Fix the issue by using `git__strndup`, as was already done in the other location. Furthermore, add allocation checks to both locations to detect out-of-memory situations.

3223f5de

2019-10-19T15:52:35

patch_parse: reject empty path names When parsing patch headers, we currently accept empty path names just fine, e.g. a line "--- \n" would be parsed as the empty filename. This is not a valid patch format and may cause `NULL` pointer accesses at a later place as `git_buf_detach` will return `NULL` in that case. Reject such patches as malformed with a nice error message.

db73191b

2019-10-19T15:42:54

patch_parse: reject patches with multiple old/new paths It's currently possible to have patches with multiple old path name headers. As we didn't check for this case, this resulted in a memory leak when overwriting the old old path with the new old path because we simply discarded the old pointer. Instead of fixing this by free'ing the old pointer, we should reject such patches altogether. It doesn't make any sense for the "---" or "+++" markers to occur multiple times within a patch n the first place. This also implicitly fixes the memory leak.

fc60777e

2019-10-16T22:11:33

patch_parse: handle patches without extended headers 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.

fceedda5

2019-10-11T12:44:09

refs: unlock unmodified refs on transaction commit Refs which are locked in a transaction without an altered target, still should to be unlocked on `git_transaction_commit`. `git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free` cannot be controlled in all situations. Some binding libs call `git_transaction_free` on garbage collection or not at all if the application exits before and don't provide public access to `git_transaction_free`. It is better to release locks as soon as possible.

5aca2444

2019-10-10T15:28:46

refs: fix locks getting forcibly removed The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.

85ab27c8

2019-09-28T15:52:25

patch_parse: handle patches with new empty files 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.

3c605da6

2019-09-19T12:24:06

buffer: fix printing into out-of-memory buffer Before printing into a `git_buf` structure, we always call `ENSURE_SIZE` first. This macro will reallocate the buffer as-needed depending on whether the current amount of allocated bytes is sufficient or not. If `asize` is big enough, then it will just do nothing, otherwise it will call out to `git_buf_try_grow`. But in fact, it is insufficient to only check `asize`. When we fail to allocate any more bytes e.g. via `git_buf_try_grow`, then we set the buffer's pointer to `git_buf__oom`. Note that we touch neither `asize` nor `size`. So if we just check `asize > targetsize`, then we will happily let the caller of `ENSURE_SIZE` proceed with an out-of-memory buffer. As a result, we will print all bytes into the out-of-memory buffer instead, resulting in an out-of-bounds write. Fix the issue by having `ENSURE_SIZE` verify that the buffer is not marked as OOM. Add a test to verify that we're not writing into the OOM buffer.

93dc8a04

2019-09-19T12:46:37

buffer: fix infinite loop when growing buffers When growing buffers, we repeatedly multiply the currently allocated number of bytes by 1.5 until it exceeds the requested number of bytes. This has two major problems: 1. If the current number of bytes is tiny and one wishes to resize to a comparatively huge number of bytes, then we may need to loop thousands of times. 2. If resizing to a value close to `SIZE_MAX` (which would fail anyway), then we probably hit an infinite loop as multiplying the current amount of bytes will repeatedly result in integer overflows. When reallocating buffers, one typically chooses values close to 1.5 to enable re-use of resulting memory holes in later reallocations. But because of this, it really only makes sense to use a factor of 1.5 _once_, but not looping until we finally are able to fit it. Thus, we can completely avoid the loop and just opt for the much simpler algorithm of multiplying with 1.5 once and, if the result doesn't fit, just use the target size. This avoids both problems of looping extensively and hitting overflows. This commit also adds a test that would've previously resulted in an infinite loop.

8c99ccc5

2019-09-10T11:14:36

open:fix memory leak when passing NULL to git_repository_open_ext

99b89a9c

2019-08-24T12:14:31

ignore: correct handling of nested rules overriding wild card unignore problem: filesystem_iterator loads .gitignore files in top-down order. subsequently, ignore module evaluates them in the order they are loaded. this creates a problem if we have unignored a rule (using a wild card) in a sub dir and ignored it again in a level further below (see the test included in this patch). solution: process ignores in reverse order. closes #4963

5e5a9cce

2019-08-28T23:18:31

apply: Test for EOFNL mishandling when several hunks are processed Introduce an unit test to validate that git_apply__patch() properly handles EOFNL changes in case of patches with several hunks.

ae9b333a

2019-08-27T13:10:53

apply: free test data

deda897a

2019-08-21T15:03:50

apply: Test for git_apply_to_tree failures when new files are added Introduce an unit test to validate if git_apply_to_tree() fails when an applied patch adds new files.

16dbedc9

2019-07-11T12:12:04

patch_parse: ensure valid patch output with EOFNL

fe012c60

2019-07-05T11:06:33

patch_parse: handle missing newline indicator in old file When either the old or new file contents have no newline at the end of the file, then git-diff(1) will print out a "\ No newline at end of file" indicator. While we do correctly handle this in the case where the new file has this indcator, we fail to parse patches where the old file is missing a newline at EOF. Fix this bug by handling and missing newline indicators in the old file. Add tests to verify that we can parse such files.

782bc334

2019-07-05T09:35:43

patch_parse: do not depend on parsed buffer's lifetime When parsing a patch from a buffer, we let the patch lines point into the original buffer. While this is efficient use of resources, this also ties the lifetime of the parsed patch to the parsed buffer. As this behaviour is not documented anywhere in our API it is very surprising to its users. Untie the lifetime by duplicating the lines into the parsed patch. Add a test that verifies that lifetimes are indeed independent of each other.

2ce6eddf

2019-02-21T08:30:22

tests: apply: verify that we correctly truncate the source buffer Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.

a673ce14

2019-12-03T23:15:47

path: support non-ascii drive letters on dos Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.

6bd07401

2019-12-03T19:50:18

index: ensure that we respect core.protectNTFS=false Users may want to turn off core.protectNTFS, perhaps to import (and then repair) a broken tree. Ensure that core.protectNTFS=false is honored.

0d8b9373

2019-12-03T23:23:02

tree: ensure we protect NTFS paths everywhere

50a33c30

2019-12-03T19:24:59

path: protect NTFS everywhere Enable core.protectNTFS by default everywhere and in every codepath, not just on checkout.

aa0902f4

2019-12-03T19:17:41

test: ensure we can't add a protected path Test that when we enable core.protectNTFS that we cannot add platform-specific invalid paths to the index.

f26b03d9

2019-12-03T19:01:00

test: improve badname verification test The name of the `add_invalid_filename` function suggests that we _want_ to add an invalid filename. Rename the function to show that we expect to _fail_ to add the invalid filename.

94589e7c

2019-12-03T18:57:16

test: ensure treebuilder validate new protection rules Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for using the treebuilder when core.protectNTFS is set.

fd255d2c

2019-12-03T18:56:31

test: ensure index adds validate new protection rules Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for adding to the index when core.protectNTFS is set.

a336ed18

2019-12-03T18:49:23

test: improve badname verification test The name of the `write_invalid_filename` function suggests that we _want_ to write an invalid filename. Rename the function to show that we expect to _fail_ to write the invalid filename.

ac0b2ef1

2019-09-18T16:33:18

path: also guard `.gitmodules` against NTFS Alternate Data Streams We just safe-guarded `.git` against NTFS Alternate Data Stream-related attack vectors, and now it is time to do the same for `.gitmodules`. Note: In the added regression test, we refrain from verifying all kinds of variations between short names and NTFS Alternate Data Streams: as the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it is enough to test one in order to know that all of them are guarded against. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

460a9fdc

2019-09-18T14:32:05

Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS A little-known feature of NTFS is that it offers to store metadata in so-called "Alternate Data Streams" (inspired by Apple's "resource forks") that are copied together with the file they are associated with. These Alternate Data Streams can be accessed via `<file name>:<stream name>:<stream type>`. Directories, too, have Alternate Data Streams, and they even have a default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and `abc::$INDEX_ALLOCATION/` are actually equivalent. This is of course another attack vector on the Git directory that we definitely want to prevent. On Windows, we already do this incidentally, by disallowing colons in file/directory names. While it looks as if files'/directories' Alternate Data Streams are not accessible in the Windows Subsystem for Linux, and neither via CIFS/SMB-mounted network shares in Linux, it _is_ possible to access them on SMB-mounted network shares on macOS. Therefore, let's go the extra mile and prevent this particular attack _everywhere_. To keep things simple, let's just disallow *any* Alternate Data Stream of `.git`. This is libgit2's variant of CVE-2019-1352. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

7bf80ab0

2019-09-18T15:25:02

Protect against 8.3 "short name" attacks also on Linux/macOS The Windows Subsystem for Linux (WSL) is getting increasingly popular, in particular because it makes it _so_ easy to run Linux software on Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to `/mnt/c/`, no need to set that up manually). Unfortunately, files/directories on the Windows drives can be accessed via their _short names_, if that feature is enabled (which it is on the `C:` drive by default). Which means that we have to safeguard even our Linux users against the short name attacks. Further, while the default options of CIFS/SMB-mounts seem to disallow accessing files on network shares via their short names on Linux/macOS, it _is_ possible to do so with the right options. So let's just safe-guard against short name attacks _everywhere_. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

48043516

2019-09-18T15:08:56

cl_git_fail: do not report bogus error message When we expect a checkout operation to fail, but it succeeds, we actually do not want to see the error messages that were generated in the meantime for errors that were handled gracefully by the code (e.g. when an object could not be found in a pack: in this case, the next backend would have been given a chance to look up the object, and probably would have found it because the checkout succeeded, after all). Which means that in the specific case of `cl_git_fail()`, we actually want to clear the global error state _after_ evaluating the command: we know that any still-available error would be bogus, seeing as the command succeeded (unexpectedly). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

98c11905

2019-03-20T12:28:45

Correctly write to missing locked global config Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string. (cherry picked from commit e44110dbbfc9d50b883d73fbb6c9e3b53732ec9d)

9b698978

2019-04-12T08:54:06

git_repository_init: stop traversing at windows root Stop traversing the filesystem at the Windows directory root. We were calculating the filesystem root for the given directory to create, and walking up the filesystem hierarchy. We intended to stop when the traversal path length is equal to the root path length (ie, stopping at the root, since no path may be shorter than the root path). However, on Windows, the root path may be specified in two different ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter. `git_path_dirname_r` returns the path _without_ a trailing slash, even for the Windows root. As a result, during traversal, we need to test that the traversal path is _less than or equal to_ the root path length to determine if we've hit the root to ensure that we stop when our traversal path is `Z:` and our calculated root path was `Z:\`.

21baf7ab

2019-04-05T10:22:46

ignore: treat paths with trailing "/" as directories The function `git_ignore_path_is_ignored` is there to test the ignore status of paths that need not necessarily exist inside of a repository. This has the implication that for a given path, we cannot always decide whether it references a directory or a file, and we need to distinguish those cases because ignore rules may treat those differently. E.g. given the following gitignore file: * !/**/ we'd only want to unignore directories, while keeping files ignored. But still, calling `git_ignore_path_is_ignored("dir/")` will say that this directory is ignored because it treats "dir/" as a file path. As said, the `is_ignored` function cannot always decide whether the given path is a file or directory, and thus it may produce wrong results in some cases. While this is unfixable in the general case, we can do better when we are being passed a path name with a trailing path separator (e.g. "dir/") and always treat them as directories.

71424f63

2019-03-22T23:56:10

patch_parse.c: Handle CRLF in parse_header_start

4ec209cd

2019-03-29T12:30:37

tests: diff: test parsing diffs with a new file with spaces in its path Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.

1df7d27a

2019-03-20T13:24:07

ignore: move tests from status to attr ignore suite

93971ca6

2019-03-15T13:08:18

ignore: add additional test cases

12bc7181

2019-03-14T15:51:15

ignore: Do not match on prefix of negated patterns Matching on the prefix of a negated pattern was triggering false negatives on siblings of that pattern. e.g. Given the .gitignore: dir/* !dir/sub1/sub2/** The path `dir/a.text` would not be ignored.

aa877e09

2019-03-14T09:59:27

Implement failing test for gitignore of complex subdirectory negation When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored

5189beb0

2019-02-16T19:55:30

Fix a memory leak in odb_otype_fast() This change frees a copy of a cached object in odb_otype_fast().

24ac9e0c

2019-02-13T23:26:54

deprecation: ensure we GIT_EXTERN deprecated funcs Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples.

3fba5891

2019-01-20T23:53:33

test: cast to a char the zstream test

f25bb508

2019-01-20T23:52:50

index test: cast times explicitly Cast actual filesystem data to the int32_t that index entries store.

826d9a4d

2019-01-25T09:43:20

Merge pull request #4858 from tiennou/fix/index-ext-read index: preserve extension parsing errors

c951b825

2019-01-23T00:32:40

deprecation: define GIT_DEPRECATE_HARD internally Ensure that we do not use any deprecated functions in the library source, test code or examples.

9c5e05ad

2019-01-23T10:43:29

deprecation: move deprecated tests into their own file Move the deprecated stream tests into their own compilation unit. This will allow us to disable any preprocessor directives that apply to deprecation just for these tests (eg, disabling `GIT_DEPRECATED_HARD`).

0bf7e043

2019-01-24T12:12:04

index: preserve extension parsing errors Previously, we would clobber any extension-specific error message with an "extension is truncated" message. This makes `read_extension` correctly preserve those errors, takes responsibility for truncation errors, and adds a new message with the actual extension signature for unsupported mandatory extensions.

f673e232

2018-12-27T13:47:34

git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.

f7416509

2019-01-20T20:15:31

Fix odb foreach to also close on positive error code In include/git2/odb.h it states that callback can also return positive value which should break looping. Implementations of git_odb_foreach() and pack_backend__foreach() did not respect that.

1758636b

2019-01-19T01:38:34

Merge pull request #4939 from libgit2/ethomson/git_ref Move `git_ref_t` to `git_reference_t`

b2c2dc64

2019-01-19T01:36:40

Merge pull request #4940 from libgit2/ethomson/git_obj More `git_obj` to `git_object` updates

c352e561

2019-01-19T01:34:21

Merge pull request #4943 from libgit2/ethomson/ci ci: only run invasive tests in nightly

423d3e73

2019-01-19T00:08:05

ci: precisely identify the invasive tests

abe23675

2019-01-17T20:09:05

Merge pull request #4925 from lhchavez/fix-a-bunch-of-warnings Fix a bunch of warnings

cd350852

2019-01-17T10:40:13

object_type: GIT_OBJECT_BAD is now GIT_OBJECT_INVALID We use the term "invalid" to refer to bad or malformed data, eg `GIT_REF_INVALID` and `GIT_EINVALIDSPEC`. Since we're changing the names of the `git_object_t`s in this release, update it to be `GIT_OBJECT_INVALID` instead of `BAD`.

ed8cfbf0

2019-01-17T00:32:31

references: use new names in internal usage Update internal usage to use the `git_reference` names for constants.

7a43a892

2019-01-15T00:42:14

Convert tests/resources/push.sh to LF endings This changes that file to use UNIX line-endings, which makes sense since this is a UNIXy file.

a653f967

2019-01-14T16:08:05

Get rid of some test files that were accidentally committed

35d86c77

2019-01-14T10:14:36

proxy: fix crash on remote connection with GIT_PROXY_AUTO but no proxy is detected

54ae0528

2019-01-14T01:25:05

tests: fix test expectation mismatch

1b4ba844

2019-01-11T11:53:54

ci: enable some of the invasive testcases

8b599528

2019-01-08T17:26:14

Fix Linux warnings This change fixes -Wmaybe-uninitialized and -Wdeprecated-declarations warnings on Linux builds

321d19c1

2019-01-06T08:36:06

Windows is hard.

b5e8272f

2019-01-06T08:29:56

Attempt at fixing the MingW64 compilation It seems like MingW64's size_t is defined differently than in Linux.

7b453e7e

2019-01-05T22:12:48

Fix a bunch of warnings This change fixes a bunch of warnings that were discovered by compiling with `clang -target=i386-pc-linux-gnu`. It turned out that the intrinsics were not necessarily being used in all platforms! Especially in GCC, since it does not support __has_builtin. Some more warnings were gleaned from the Windows build, but I stopped when I saw that some third-party dependencies (e.g. zlib) have warnings of their own, so we might never be able to enable -Werror there.

50d4688c

2019-01-04T13:41:50

tests: add missing asserts CID 1398597, 1398598

9084712b

2019-01-03T12:01:52

Merge pull request #4904 from libgit2/ethomson/crlf Update CRLF filtering to match modern git

e385e647

2018-12-19T12:08:17

checkout::crlf: ensure success Wrap function calls in the `checkout::crlf` tests with `cl_git_pass`, `cl_assert`, etc. to ensure that they're successful.

bc219657

2018-12-19T11:01:55

Merge pull request #4833 from csware/drop-empty-dirs Remove empty (sub-)directories when deleting refs

0f299365

2018-12-14T14:29:36

annotated_commit: add failing test for looking up from annotated tag

2a9b0102

2015-01-23T14:16:34

Additional core.autocrlf and core.safecrlf tests This is a cherry-pick of the tests from the following commits: core.autocrlf=true and core.safecrlf=true did not fail on LF-only file as vanilla git does Adding a CRLF-file with core.autocrlf=input and core.safecrlf=true does not fail as with vanilla git Make files with #CR!=#CRLF not fail with core.safecrlf=true Reported-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Signed-off-by: Sven Strickroth <email@cs-ware.de>

59b054cb

2018-12-03T13:54:32

index::crlf: better error reporting in core git tests Don't simply fail when the expected output does not match the data in the index; instead, provide a detailed output about the system, file, and settings that caused the failure so that developers can better isolate the problem(s).

021a08b0

2018-12-01T22:33:16

index::crlf: simplify test case

e417fd99

2015-07-01T17:00:16

crlf tests: use known-good data produced by git Given a variety of combinations of core.autocrlf, core.safecrlf settings and attributes settings, test that we add files to index the same way (regarding OIDs and fatal errors) as a known-good test resource created by git.git. Signed-off-by: Sven Strickroth <email@cs-ware.de>

3d804063

2018-12-01T21:46:51

crlf_data: add corpus of known-good odb-filtered data Use the crlf data scripts to produce a corpus of known-good data in "git" format (aka ODB format) from a variety of files with different line endings. `git` created these files running `git add` to stage the contents then extracting the data from the repository. We'll use these to ensure that we create identical contents when we add files into the index.

a0ab90b8

2018-12-01T21:53:07

crlf: re-use existing crlf script to create odb Re-use the existing crlf data generation script for creating the to-odb dataset. Also, store the actual file contents instead of the ID so that we can identify differences instead of detecting that differences exist.

9065160b

2015-07-01T16:55:06

crlf: script to generate expected crlf data for adding files to index Include a shell script that will generate the expected data of OIDs and failures for calling git.git to capture its output as a test resource. Right now, there is no need to differentiate different systems as git behaves the same on all systems IIRC. Signed-off-by: Sven Strickroth <email@cs-ware.de>

c3169e6f

2018-12-01T19:59:41

checkout::crlf clear the crlf workdir for checkout After sandboxing the crlf directory, remove the working directory contents. This allows us to package data within the crlf directory (for simplicity, this allows us to script the to-odb and to-workdir crlf filter conversion data in a single location).

13a8bc92

2018-12-01T18:32:01

crlf_data: move to a "to_workdir" folder Move the crlf_data folders reponsible for holding the state of the filters going into the working directory to "to_workdir" variations of the folder name to accommodate future growth into the "to odb" filter variation. Update the script to create these new folders as appopriate.

168fe39b

2018-11-28T14:26:57

object_type: use new enumeration names Use the new object_type enumeration names within the codebase.

18e71e6d

2018-11-28T13:31:06

index: use new enum and structure names Use the new-style index names throughout our own codebase.

0ddc6094

2018-11-30T09:46:14

Merge pull request #4770 from tiennou/feature/merge-analysis-any-branch Allow merge analysis against any reference

e7873eb2

2018-11-29T08:00:31

Merge pull request #4888 from TheBB/add-cb revwalk: Allow changing hide_cb

487233fa

2018-11-29T07:21:41

Merge pull request #4895 from pks-t/pks/unused-warnings Unused function warnings

a904fc6d

2018-11-28T20:31:30

Merge pull request #4870 from libgit2/ethomson/proxy Add builtin proxy support for the http transport

02bb39f4

2018-11-22T08:49:09

stream registration: take an enum type Accept an enum (`git_stream_t`) during custom stream registration that indicates whether the registration structure should be used for standard (non-TLS) streams or TLS streams.

df2cc108

2018-11-18T10:29:07

stream: provide generic registration API Update the new stream registration API to be `git_stream_register` which takes a registration structure and a TLS boolean. This allows callers to register non-TLS streams as well as TLS streams. Provide `git_stream_register_tls` that takes just the init callback for backward compatibliity.

45054732

2018-10-29T10:45:59

tests: optionally ignore https cert validation For testing, we may wish to use a man-in-the-middle proxy that can inspect the CONNECT traffic to our test endpoints. For this, we will need to accept the proxy's certificate, which will not be valid for the true endpoint. Add a new environment variable, GITTEST_REMOTE_SSL_NOVERIFY to disable https certificate validation for the tests.

43b592ac

2018-10-25T08:49:01

tls: introduce a wrap function Introduce `git_tls_stream_wrap` which will take an existing `stream` with an already connected socket and begin speaking TLS on top of it. This is useful if you've built a connection to a proxy server and you wish to begin CONNECT over it to tunnel a TLS connection. Also update the pluggable TLS stream layer so that it can accept a registration structure that provides an `init` and `wrap` function, instead of a single initialization function.

6ba3e6af

2018-11-18T21:53:48

proxy tests: rename credential callback Rename credential callback to proxy_cred_cb to match new cert callback.

394ae7e1

2018-10-22T17:35:35

proxy tests: support self-signed proxy cert Give the proxy tests a proxy certificate callback, and allow self-signed certificates when the `GITTEST_REMOTE_PROXY_SELFSIGNED` environment variable is set (to anything). In that case, simply compare the hostname from the callback to the hostname that we connected to.

4ecc14cd

2018-10-21T23:47:53

tests: support optional PROXY_SCHEME As we want to support HTTPS proxies, support an optional `GITTEST_REMOTE_PROXY_SCHEME` environment variable for tests that will allow for HTTPS support. (When unset, the tests default to HTTP proxies.)

de60d9b4

2018-10-21T21:00:37

tests: PROXY_URL is more accurately PROXY_HOST Change the `GITTEST_REMOTE_PROXY_URL` environment variable to be `GITTEST_REMOTE_PROXY_HOST`, since it is a host:port combination, not an actual URL. (We cannot use a URL here since we may want to include the username:password combination in the constructed URL.)

thodg/libgit2/tests

tests

Log