kmx git

Commit	Date	Message
4e746d80	2018-11-05T15:49:11	test: ensure applying a patch can't delete a file twice
f8b9493b	2018-11-05T15:46:08	apply: test re-adding a file after removing it Ensure that we can add a file back after it's been removed. Update the renamed/deleted validation in application to not apply to deltas that are adding files to support this.
78580ad3	2018-11-05T15:34:59	apply: test modifying a file after renaming it Ensure that we cannot modify a file after it's been renamed out of the way. If multiple deltas exist for a single path, ensure that we do not attempt to modify a file after it's been renamed out of the way. To support this, we must track the paths that have been removed or renamed; add to a string map when we remove a path and remove from the string map if we recreate a path. Validate that we are not applying to a path that is in this map, unless the delta is a rename, since git supports renaming one file to two different places in two different deltas. Further, test that we cannot apply a modification delta to a path that will be created in the future by a rename (a path that does not yet exist.)
605066ee	2018-11-05T14:37:35	apply: test renaming a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. If there exists a delta that modifies a file followed by a delta that renames that file, then both will be captured. The modification delta will be applied and the resulting file will be staged with the original filename. The rename delta will be independently applied - to the original file (not the modified file from the original delta) and staged independently.
df4258ad	2018-11-04T13:01:03	apply: handle multiple deltas to the same file git allows a patch file to contain multiple deltas to the same file: although it does not produce files in this format itself, this could be the result of concatenating two different patch files that affected the same file. git apply behaves by applying this next delta to the existing postimage of the file. We should do the same. If we have previously seen a file, and produced a postimage for it, we will load that postimage and apply the current delta to that. If we have not, get the file from the preimage.
620ac9c2	2017-04-11T14:41:57	patch: add tests for aborting hunk callback
72630572	2017-03-30T22:40:47	patch: add support for partial patch application Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.
c71e964a	2018-11-04T12:21:57	apply: test rename 1 to 2 Test that a patch can contain two deltas that appear to rename an initial source file to two different destination paths. Git creates both target files with the initial source contents; ensure that we do, too.
47cc5f85	2018-09-29T19:32:51	apply: introduce a hunk callback Introduce a callback to patch application that allows consumers to cancel hunk application.
bd682f3e	2018-11-04T19:01:57	apply: test that we can't rename a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. However if there exists a delta that renames a file, it must be first, so that other deltas can reference the resulting target file. git enforces this (`error: already exists in index`), so ensure that we do, too.
56a2ae0c	2018-11-04T12:18:01	apply: test rename 2 to 1 Test that we can apply a patch that renames two different files to the same target filename. Git itself handles this scenario in a last-write wins, such that the rename listed last is the one persisted in the target. Ensure that we do the same.
398d8bfe	2018-07-16T17:19:08	apply tests: tests a diff w/ many small changes
b8840db7	2018-07-10T16:18:45	apply tests: test delta callback skip Test that we can return a non-zero value from the apply delta callback and it will skip the application of a given delta.
235dc9b2	2018-11-04T12:05:46	apply: test circular rename Test a rename from A->B simultaneous with a rename from B->A.
db6b1164	2018-07-10T16:13:17	apply tests: test delta callback errors Test that we can return an error from the apply delta callback and the error code is propagated back to the caller.
a3c1070c	2018-11-04T14:07:22	apply: test modify delta after rename delta Ensure that we can apply a delta after renaming a file.
89b5a56e	2018-11-04T11:58:20	apply: test rename A -> B -> C scenarios Test that we can rename some file from B->C and then rename some other file from A->B. Do this with both exact rename patches (eg `rename from ...` / `rename to ...`) and patches that remove the files and replace them entirely.
6fecf4d1	2018-11-04T11:47:46	apply: handle exact renames Deltas containing exact renames are special; they simple indicate that a file was renamed without providing additional metadata (like the filemode). Teach the reader to provide the file mode and use the preimage's filemode in the case that the delta does not provide one.)
07e71bfa	2018-11-04T13:14:20	apply: test multiple deltas to new file
12f9ac17	2018-11-04T11:26:42	apply: validate unchanged mode when applying both When applying to both the index and the working directory, ensure that the working directory's mode matches the index's mode. It's not sufficient to look only at the hashed object id to determine that the file is unchanged, git also takes the mode into account.
b73a42f6	2018-11-04T10:48:23	apply: test a patch with rename and modification Create a test applying a patch with a rename and a modification of a file.
37b25ac5	2018-07-08T16:12:58	apply: move location to an argument, not the opts Move the location option to an argument, out of the options structure. This allows the options structure to be re-used for functions that don't need to know the location, since it's implicit in their functionality. For example, `git_apply_tree` should not take a location, but is expected to take all the other options.
eb76e985	2018-07-01T21:21:25	apply tests: ensure mode changes occur Test that a mode change is reflected in the working directory or index.
5c63ce79	2018-07-01T11:10:03	apply tests: test with CR/LF filtering Ensure that we accurately CR/LF filter when reading from the working directory. If we did not, we would erroneously fail to apply the patch because the index contents did not match the working directory contents.
813f0802	2018-07-01T15:14:36	apply: validate workdir contents match index for BOTH When applying to both the index and the working directory, ensure that the index contents match the working directory. This mirrors the requirement in `git apply --index`. This also means that - along with the prior commit that uses the working directory contents as the checkout baseline - we no longer expect conflicts during checkout. So remove the special-case error handling for checkout conflicts. (Any checkout conflict now would be because the file was actually modified between the start of patch application and the checkout.)
3b674660	2018-07-01T13:46:59	apply tests: ensure we can patch a modified file Patch application need not be on an unmodified file; applying to an already changed file is supported provided the patch still applies cleanly. Add tests that modifies the contents of a file then applies the patch and ensures that the patch applies cleanly, and the original changes are also kept.
4ff829e9	2018-06-30T17:20:03	apply tests: test index+workdir application Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates `git apply --index`, updating both the index and the working directory with the postimage.
9db66c79	2018-06-29T12:50:38	apply test: apply with non-conflicting changes Ensure that we can apply to the working directory or the index when the application target is modified, so long as there are not conflicting changes to the items.
771bd81e	2018-06-29T12:40:16	apply tests: ensure apply failures leave index unmodified
2bd3cfea	2018-06-29T11:43:55	apply tests: modified wd items are ok when applying to index When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure that items modified in the working directory do not conflict with the application.
d7090ee4	2018-06-28T17:26:24	apply tests: ensure we can add and remove files from the index Add a test that adds a new file, and another that removes a file when applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.
9d81defa	2018-06-28T16:26:08	apply tests: GIT_APPLY_LOCATION_INDEX with parsed patches
eef34e4e	2018-06-28T16:24:21	apply tests: GIT_APPLY_LOCATION_INDEX with generated patches Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which emulates `git apply --cached`.
c010c93b	2018-06-27T16:50:07	apply tests: move helpers into common area
35d525b0	2018-06-26T09:19:12	apply: test that failures don't dirty workdir Ensure that when a patch application fails (due to a conflict in the working directory, for example) that we do not half-apply the patch or otherwise leave the working directory dirty. This is rather obvious in our current apply implementation (we do a two step process: one to create the post-image and one to check it out) but this test is a safety net for future refactoring or improvements.
973bf0c8	2018-06-25T20:49:22	apply: test a patch can be applied even with a modified index Ensure that we can apply a patch to the working directory, even to files that are modified in the index (as long as the working directory contents match the preimage - such that the working directory is unmodified from HEAD).
553395dc	2018-06-25T20:21:01	apply: test that the index is not modified Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that patch application does not update the index, only the working directory.
0eb63b9f	2018-06-25T19:50:35	apply tests: separate common patch hunks Move the commonly-used patch hunks into a single constant location. This allows us to avoid re-declaring them in each test, and allows us to compose them to build a larger patch file that includes all the hunks.
702d4bec	2018-06-26T15:26:37	apply tests: use `git_iterator_foreach` for tests Use the new `git_iterator_foreach` API to validate the workdir against the expected workdir values instead of using the paired/multi iterator comparison callback. This allows us to use the `git_iterator_foreach` to validate the index as well, instead of assuming that the index and HEAD must always match.
9c34c996	2018-06-25T17:03:14	apply: handle file additions Don't attempt to read the postimage file during a file addition, simply use an empty buffer as the postimage. Also, test that we can handle file additions.
3b5378c5	2018-06-25T16:27:06	apply: handle file deletions If the file was deleted in the postimage, do not attempt to update the target. Instead, ignore it and simply allow it to stay removed in our computed postimage. Also, test that we can handle file deletions.
af3287f8	2018-06-22T19:27:19	apply: test `git_apply` with a parsed patch Ensure that we can apply a simple patch to the working directory when we have parsed it from a patch file.
ff296b71	2018-03-19T19:50:52	apply: test `git_apply` application to a workdir Introduce a standard test applying a diff to a working directory with no complications.
02b1083a	2018-01-28T23:25:07	apply: introduce `git_apply_tree` Introduce `git_apply_tree`, which will apply a `git_diff` to a given `git_tree`, allowing an in-memory patch application for a repository.
2b12dcf6	2018-03-19T19:45:11	iterator: optionally hash filesystem iterators Optionally hash the contents of files encountered in the filesystem or working directory iterators. This is not expected to be used in production code paths, but may allow us to simplify some test contexts. For working directory iterators, apply filters as appropriate, since we have the context able to do it.
b5ae83bf	2018-10-31T08:47:10	Merge pull request #4860 from tiennou/ci/macos-leaks CI: Fix macOS leak detection
0e69485e	2018-10-23T20:34:47	clar: provide a way to run some shell before exiting
623647af	2018-10-26T12:33:59	Merge pull request #4864 from pks-t/pks/object-parse-fixes Object parse fixes
7655b2d8	2018-10-19T10:29:19	commit: fix reading out of bounds when parsing encoding The commit message encoding is currently being parsed by the `git__prefixcmp` function. As this function does not accept a buffer length, it will happily skip over a buffer's end if it is not `NUL` terminated. Fix the issue by using `git__prefixncmp` instead. Add a test that verifies that we are unable to parse the encoding field if it's cut off by the supplied buffer length.
c2e3d8ef	2018-10-25T12:01:18	tests: add tests that exercise commit parsing We currently do not have any test suites dedicated to parsing commits from their raw representations. Add one based on `git_object__from_raw` to be able to test special cases more easily.
ee11d47e	2018-10-19T09:47:50	tag: fix out of bounds read when searching for tag message When parsing tags, we skip all unknown fields that appear before the tag message. This skipping is done by using a plain `strstr(buffer, "\n\n")` to search for the two newlines that separate tag fields from tag message. As it is not possible to supply a buffer length to `strstr`, this call may skip over the buffer's end and thus result in an out of bounds read. As `strstr` may return a pointer that is out of bounds, the following computation of `buffer_end - buffer` will overflow and result in an allocation of an invalid length. Fix the issue by using `git__memmem` instead. Add a test that verifies parsing the tag fails not due to the allocation failure but due to the tag having no message.
4c738e56	2018-10-19T09:44:14	tests: add tests that exercise tag parsing While the tests in object::tag::read exercises reading and parsing valid tags from the ODB, they barely try to verify that the parser fails in a sane way when parsing invalid tags. Create a new test suite object::tag::parse that directly exercise the parser by using `git_object__from_raw` and add various tests for valid and invalid tags.
83e8a6b3	2018-10-18T16:08:46	util: provide `git__memmem` function Unfortunately, neither the `memmem` nor the `strnstr` functions are part of any C standard but are merely extensions of C that are implemented by e.g. glibc. Thus, there is no standardized way to search for a string in a block of memory with a limited size, and using `strstr` is to be considered unsafe in case where the buffer has not been sanitized. In fact, there are some uses of `strstr` in exactly that unsafe way in our codebase. Provide a new function `git__memmem` that implements the `memmem` semantics. That is in a given haystack of `n` bytes, search for the occurrence of a byte sequence of `m` bytes and return a pointer to the first occurrence. The implementation chosen is the "Not So Naive" algorithm from [1]. It was chosen as the implementation is comparably simple while still being reasonably efficient in most cases. Preprocessing happens in constant time and space, searching has a time complexity of O(n*m) with a slightly sub-linear average case. [1]: http://www-igm.univ-mlv.fr/~lecroq/string/
bea65980	2018-10-25T11:21:14	Merge pull request #4851 from pks-t/pks/strtol-removal strtol removal
2e34efaa	2018-10-21T13:10:06	buf::oom tests: use custom allocator for oom failures Create a custom allocator for the `buf::oom` tests that will fail with out-of-memory errors in predictable ways. We were previously trying to guess the way that various allocators on various platforms would fail in a way such that `malloc`/`realloc` would return `NULL` (instead of aborting the application, or appearing suspicious to various instrumentation or static code analysis tools like valgrind.) Introduce a fake `malloc` and `realloc` that will return `NULL` on allocations requesting more than 100 bytes. Otherwise, we proxy to the default allocator. (It's important to use the _default_ allocator, not just call `malloc`, since the default allocator on Windows CI builds may be the debugging C runtime allocators which would not be compatible with a standard `malloc`.)
415a8ae9	2018-09-13T13:27:07	tests: don't run buf::oom on 32-bit systems On a 32-bit Linux systems, the value large enough to make malloc guarantee a failure is also large enough that valgrind considers it "fishy". Skip this test on those systems entirely.
7c791f3d	2018-10-20T20:25:51	Merge pull request #4852 from libgit2/ethomson/unc_paths Win32 path canonicalization refactoring
6cc14ae3	2018-10-20T20:22:04	Merge pull request #4840 from libgit2/cmn/validity-tree-from-unowned-index Check object existence when creating a tree from an index
a2f9f94b	2018-10-20T20:18:04	Merge branch 'issue-4203'
c79e6081	2018-10-20T19:08:16	checkout: fix test fixture missing objects The testrepo test fixture has an index file that's damaged, missing an object. The index previously had an entry of `src/index.c` with id 3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in the repository. This commit adds an object to the repository and updates the index to use that existing blob. Similarly, the index has an entry for `readme` with an id of 97328ac7e3bd0bcd3900cb3e7a624d71dd0df888. This can be restored from other test repositories. With these fixed, now the write tree from index tests can pass since they validate object existence.
ea19efc1	2018-10-18T15:08:56	util: fix out of bounds read in error message When an integer that is parsed with `git__strntol32` is too big to fit into an int32, we will generate an error message that includes the actual string that failed to parse. This does not acknowledge the fact that the string may either not be NUL terminated or alternative include additional characters after the number that is to be parsed. We may thus end up printing characters into the buffer that aren't the number or, worse, read out of bounds. Fix the issue by utilizing the `endptr` that was set by `git__strntol64`. This pointer is guaranteed to be set to the first character following the number, and we can thus use it to compute the width of the number that shall be printed. Create a test to verify that we correctly truncate the number.
16fd9ba9	2018-10-17T11:34:38	win32: more tests for `git_win32_remove_path`
b2e85f98	2018-10-17T08:48:43	win32: rename `git_win32__canonicalize_path` The internal API `git_win32__canonicalize_path` is far, far too easily confused with the internal API `git_win32_path_canonicalize`. The former removes the namespace prefix from a path (eg, given `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given `\\?\UNC\server\share`, it returns `\\server\share`). As such, rename it to `git_win32_path_remove_namespace`. `git_win32_path_canonicalize` remains unchanged.
39087ab8	2018-10-18T12:11:33	tests: core::strtol: test for some more edge-cases Some edge cases were currently completely untested, e.g. parsing numbers greater than INT64_{MIN,MAX}, truncating buffers by length and invalid characters. Add tests to verify that the system under test performs as expected.
8d7fa88a	2018-10-18T12:04:07	util: remove `git__strtol32` The function `git__strtol32` can easily be misused when untrusted data is passed to it that may not have been sanitized with trailing `NUL` bytes. As all usages of this function have now been removed, we can remove this function altogether to avoid future misuse of it.
68deb2cc	2018-10-18T11:37:10	util: remove unsafe `git__strtol64` function The function `git__strtol64` does not take a maximum buffer length as parameter. This has led to some unsafe usages of this function, and as such we may consider it as being unsafe to use. As we have now eradicated all usages of this function, let's remove it completely to avoid future misuse.
1cbc9604	2018-09-28T10:57:50	config: add failing test for no newline after section header
814e7acb	2018-10-12T12:38:06	Merge pull request #4842 from nelhage/fuzz-config-memory config: Port config_file_fuzzer to the new in-memory backend.
2d449a11	2018-10-09T02:42:14	config: Refactor `git_config_backend_from_string` to take a length
fbc0dcda	2018-10-08T13:01:23	index: add failing test for writing an invalid tree from an unowned index When the index does not belong to any repository, we do not do any checks of the target id going in as we cannot verify that it exists. When we then write it out to a repository as a tree, we fail to perform the object existance and type-matching check that we do in other code-paths. This leads to being able to write trees which point to non-existent blobs even with strict object creation enabled.
838a2f29	2018-10-07T12:00:48	Merge pull request #4828 from csware/git_futils_rmdir_r_failing Add some more tests for git_futils_rmdir_r and some cleanup
0cd976c8	2018-10-07T12:00:06	Merge pull request #4830 from pks-t/pks/diff-stats-rename-common diff_stats: use git's formatting of renames with common directories
a8d447f6	2018-10-05T20:13:34	Merge pull request #4837 from pks-t/cmn/reject-option-submodule-url-path submodule: ignore path and url attributes if they look like options
ce8803a2	2018-10-05T20:03:38	Merge pull request #4836 from pks-t/pks/smart-packets Smart packet security fixes
84d6f439	2018-10-05T19:53:22	Merge pull request #4832 from pks-t/pks/config-includes-null-deref config_file: properly ignore includes without "path" value
4e0bdaa8	2018-10-05T11:42:00	submodule: add failing test for option-injection protection in url and path
ad273718	2018-10-04T10:32:07	tests: sanitize file hierarchy after running rmdir tests Currently, we do not clean up after ourselves after tests in core::rmdir have created new files in the directory hierarchy. This may leave stale files and/or directories after having run tests, confusing subsequent tests that expect a pristine test environment. Most importantly, it may cause the test initialization to fail which expects being able to re-create the testing hierarchy before each test in case where another test hasn't cleaned up after itself. Fix the issue by adding a cleanup function that removes the temporary testing hierarchy after each test if it still exists.
e886ab46	2018-10-02T19:50:29	tests: Add some more tests for git_futils_rmdir_r Signed-off-by: Sven Strickroth <email@cs-ware.de>
d06d4220	2018-10-05T10:56:02	config_file: properly ignore includes without "path" value In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810.
bf662f7c	2018-10-05T10:55:29	tests: always unlink created config files While our tests in config::include create a plethora of configuration files, most of them do not get removed at the end of each test. This can cause weird interactions with tests that are being run at a later stage if these later tests try to create files or directories with the same name as any of the created configuration files. Fix the issue by unlinking all created files at the end of these tests.
dbb4a586	2018-10-05T10:27:33	tests: fix warning for implicit conversion of integer to pointer GCC warns by default when implicitly converting integers to pointers or the other way round, and commit fa48d2ea7 (vector: do not malloc 0-length vectors on dup, 2018-09-26) introduced such an implicit conversion into our vector tests. While this is totally fine in this test, as the pointer's value is never being used in the first place, we can trivially avoid the warning by instead just inserting a pointer for a variable allocated on the stack into the vector.
3f096ca5	2018-10-04T13:03:25	Fix comment style and update test code
e5090ee3	2018-10-04T11:19:28	diff_stats: use git's formatting of renames with common directories 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.
3148efd2	2018-10-04T11:13:57	tests: verify diff stats with renames in subdirectory 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.
0b3dfbf4	2018-08-09T11:13:59	smart_pkt: reorder and rename parameters of `git_pkt_parse_line` The parameters of the `git_pkt_parse_line` function are quite confusing. First, there is no real indicator what the `out` parameter is actually all about, and it's not really clear what the `bufflen` parameter refers to. Reorder and rename the parameters to make this more obvious.
a9f1ca09	2018-08-09T11:01:00	smart_pkt: fix buffer overflow when parsing "ok" packets There are two different buffer overflows present when parsing "ok" packets. First, we never verify whether the line already ends after "ok", but directly go ahead and also try to skip the expected space after "ok". Second, we then go ahead and use `strchr` to scan for the terminating newline character. But in case where the line isn't terminated correctly, this can overflow the line buffer. Fix the issues by using `git__prefixncmp` to check for the "ok " prefix and only checking for a trailing '\n' instead of using `memchr`. This also fixes the issue of us always requiring a trailing '\n'. Reported by oss-fuzz, issue 9749: Crash Type: Heap-buffer-overflow READ {*} Crash Address: 0x6310000389c0 Crash State: ok_pkt git_pkt_parse_line git_smart__store_refs Sanitizer: address (ASAN)
bc349045	2018-08-09T10:38:10	smart_pkt: fix buffer overflow when parsing "ACK" packets We are being quite lenient when parsing "ACK" packets. First, we didn't correctly verify that we're not overrunning the provided buffer length, which we fix here by using `git__prefixncmp` instead of `git__prefixcmp`. Second, we do not verify that the actual contents make any sense at all, as we simply ignore errors when parsing the ACKs OID and any unknown status strings. This may result in a parsed packet structure with invalid contents, which is being silently passed to the caller. This is being fixed by performing proper input validation and checking of return codes.
365d2720	2018-10-03T15:39:40	tests: verify parsing logic for smart packets The commits following this commit are about to introduce quite a lot of refactoring and tightening of the smart packet parser. Unfortunately, we do not yet have any tests despite our online tests that verify that our parser does not regress upon changes. This is doubly unfortunate as our online tests aren't executed by default. Add new tests that exercise the smart parsing logic directly by executing `git_pkt_parse_line`.
8ab11dd5	2018-09-30T16:40:22	Fix issue with path canonicalization for Win32 paths
1621a37d	2018-09-29T13:22:59	Merge pull request #4812 from libgit2/ethomson/ci-refactor CI: refactoring
0530d7d9	2018-09-28T18:04:23	Merge pull request #4767 from pks-t/pks/config-mem In-memory configuration
2be39cef	2018-08-10T19:38:57	config: introduce new read-only in-memory backend Now that we have abstracted away how to store and retrieve config entries, it became trivial to implement a new in-memory backend by making use of this. And thus we do so. This commit implements a new read-only in-memory backend that can parse a chunk of memory into a `git_config_backend` structure.
b944e137	2018-08-10T13:03:33	config: rename "config_file.h" to "config_backend.h" The header "config_file.h" has a list of inline-functions to access the contents of a config backend without directly messing with the struct's function pointers. While all these functions are called "git_config_file_", they are in fact completely backend-agnostic and don't care whether it is a file or not. Rename all the function to instead be backend-agnostic versions called "git_config_backend_" and rename the header to match.
ba1cd495	2018-09-28T11:10:49	Merge pull request #4784 from tiennou/fix/warnings Some warnings
367f6243	2018-09-28T11:04:06	Merge pull request #4803 from tiennou/fix/4802 index: release the snapshot instead of freeing the index
fa48d2ea	2018-09-26T19:15:35	vector: do not malloc 0-length vectors on dup
be4717d2	2018-09-18T12:12:06	path: fix "comparison always true" warning
e84914fd	2018-09-20T20:11:36	online::clone: free url and username before resetting Before resetting the url and username, ensure that we free them in case they were set by environment variables.
943181c2	2018-09-10T12:36:51	Revert "clar: introduce CLAR_XML option" This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8. Using clar to propagate the XML settings was a mistake.
d17e67d0	2018-09-08T18:54:21	clar: iterate errors in report_all / report_errors Instead of trying to have a clever iterator pattern that increments the error number, just iterate over errors in the report errors or report all functions as it's easier to reason about in this fashion.

4e746d80

2018-11-05T15:49:11

test: ensure applying a patch can't delete a file twice

f8b9493b

2018-11-05T15:46:08

apply: test re-adding a file after removing it Ensure that we can add a file back after it's been removed. Update the renamed/deleted validation in application to not apply to deltas that are adding files to support this.

78580ad3

2018-11-05T15:34:59

apply: test modifying a file after renaming it Ensure that we cannot modify a file after it's been renamed out of the way. If multiple deltas exist for a single path, ensure that we do not attempt to modify a file after it's been renamed out of the way. To support this, we must track the paths that have been removed or renamed; add to a string map when we remove a path and remove from the string map if we recreate a path. Validate that we are not applying to a path that is in this map, unless the delta is a rename, since git supports renaming one file to two different places in two different deltas. Further, test that we cannot apply a modification delta to a path that will be created in the future by a rename (a path that does not yet exist.)

605066ee

2018-11-05T14:37:35

apply: test renaming a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. If there exists a delta that modifies a file followed by a delta that renames that file, then both will be captured. The modification delta will be applied and the resulting file will be staged with the original filename. The rename delta will be independently applied - to the original file (not the modified file from the original delta) and staged independently.

df4258ad

2018-11-04T13:01:03

apply: handle multiple deltas to the same file git allows a patch file to contain multiple deltas to the same file: although it does not produce files in this format itself, this could be the result of concatenating two different patch files that affected the same file. git apply behaves by applying this next delta to the existing postimage of the file. We should do the same. If we have previously seen a file, and produced a postimage for it, we will load that postimage and apply the current delta to that. If we have not, get the file from the preimage.

620ac9c2

2017-04-11T14:41:57

patch: add tests for aborting hunk callback

72630572

2017-03-30T22:40:47

patch: add support for partial patch application Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.

c71e964a

2018-11-04T12:21:57

apply: test rename 1 to 2 Test that a patch can contain two deltas that appear to rename an initial source file to two different destination paths. Git creates both target files with the initial source contents; ensure that we do, too.

47cc5f85

2018-09-29T19:32:51

apply: introduce a hunk callback Introduce a callback to patch application that allows consumers to cancel hunk application.

bd682f3e

2018-11-04T19:01:57

apply: test that we can't rename a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. However if there exists a delta that renames a file, it must be first, so that other deltas can reference the resulting target file. git enforces this (`error: already exists in index`), so ensure that we do, too.

56a2ae0c

2018-11-04T12:18:01

apply: test rename 2 to 1 Test that we can apply a patch that renames two different files to the same target filename. Git itself handles this scenario in a last-write wins, such that the rename listed last is the one persisted in the target. Ensure that we do the same.

398d8bfe

2018-07-16T17:19:08

apply tests: tests a diff w/ many small changes

b8840db7

2018-07-10T16:18:45

apply tests: test delta callback skip Test that we can return a non-zero value from the apply delta callback and it will skip the application of a given delta.

235dc9b2

2018-11-04T12:05:46

apply: test circular rename Test a rename from A->B simultaneous with a rename from B->A.

db6b1164

2018-07-10T16:13:17

apply tests: test delta callback errors Test that we can return an error from the apply delta callback and the error code is propagated back to the caller.

a3c1070c

2018-11-04T14:07:22

apply: test modify delta after rename delta Ensure that we can apply a delta after renaming a file.

89b5a56e

2018-11-04T11:58:20

apply: test rename A -> B -> C scenarios Test that we can rename some file from B->C and then rename some other file from A->B. Do this with both exact rename patches (eg `rename from ...` / `rename to ...`) and patches that remove the files and replace them entirely.

6fecf4d1

2018-11-04T11:47:46

apply: handle exact renames Deltas containing exact renames are special; they simple indicate that a file was renamed without providing additional metadata (like the filemode). Teach the reader to provide the file mode and use the preimage's filemode in the case that the delta does not provide one.)

07e71bfa

2018-11-04T13:14:20

apply: test multiple deltas to new file

12f9ac17

2018-11-04T11:26:42

apply: validate unchanged mode when applying both When applying to both the index and the working directory, ensure that the working directory's mode matches the index's mode. It's not sufficient to look only at the hashed object id to determine that the file is unchanged, git also takes the mode into account.

b73a42f6

2018-11-04T10:48:23

apply: test a patch with rename and modification Create a test applying a patch with a rename and a modification of a file.

37b25ac5

2018-07-08T16:12:58

apply: move location to an argument, not the opts Move the location option to an argument, out of the options structure. This allows the options structure to be re-used for functions that don't need to know the location, since it's implicit in their functionality. For example, `git_apply_tree` should not take a location, but is expected to take all the other options.

eb76e985

2018-07-01T21:21:25

apply tests: ensure mode changes occur Test that a mode change is reflected in the working directory or index.

5c63ce79

2018-07-01T11:10:03

apply tests: test with CR/LF filtering Ensure that we accurately CR/LF filter when reading from the working directory. If we did not, we would erroneously fail to apply the patch because the index contents did not match the working directory contents.

813f0802

2018-07-01T15:14:36

apply: validate workdir contents match index for BOTH When applying to both the index and the working directory, ensure that the index contents match the working directory. This mirrors the requirement in `git apply --index`. This also means that - along with the prior commit that uses the working directory contents as the checkout baseline - we no longer expect conflicts during checkout. So remove the special-case error handling for checkout conflicts. (Any checkout conflict now would be because the file was actually modified between the start of patch application and the checkout.)

3b674660

2018-07-01T13:46:59

apply tests: ensure we can patch a modified file Patch application need not be on an unmodified file; applying to an already changed file is supported provided the patch still applies cleanly. Add tests that modifies the contents of a file then applies the patch and ensures that the patch applies cleanly, and the original changes are also kept.

4ff829e9

2018-06-30T17:20:03

apply tests: test index+workdir application Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates `git apply --index`, updating both the index and the working directory with the postimage.

9db66c79

2018-06-29T12:50:38

apply test: apply with non-conflicting changes Ensure that we can apply to the working directory or the index when the application target is modified, so long as there are not conflicting changes to the items.

771bd81e

2018-06-29T12:40:16

apply tests: ensure apply failures leave index unmodified

2bd3cfea

2018-06-29T11:43:55

apply tests: modified wd items are ok when applying to index When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure that items modified in the working directory do not conflict with the application.

d7090ee4

2018-06-28T17:26:24

apply tests: ensure we can add and remove files from the index Add a test that adds a new file, and another that removes a file when applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.

9d81defa

2018-06-28T16:26:08

apply tests: GIT_APPLY_LOCATION_INDEX with parsed patches

eef34e4e

2018-06-28T16:24:21

apply tests: GIT_APPLY_LOCATION_INDEX with generated patches Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which emulates `git apply --cached`.

c010c93b

2018-06-27T16:50:07

apply tests: move helpers into common area

35d525b0

2018-06-26T09:19:12

apply: test that failures don't dirty workdir Ensure that when a patch application fails (due to a conflict in the working directory, for example) that we do not half-apply the patch or otherwise leave the working directory dirty. This is rather obvious in our current apply implementation (we do a two step process: one to create the post-image and one to check it out) but this test is a safety net for future refactoring or improvements.

973bf0c8

2018-06-25T20:49:22

apply: test a patch can be applied even with a modified index Ensure that we can apply a patch to the working directory, even to files that are modified in the index (as long as the working directory contents match the preimage - such that the working directory is unmodified from HEAD).

553395dc

2018-06-25T20:21:01

apply: test that the index is not modified Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that patch application does not update the index, only the working directory.

0eb63b9f

2018-06-25T19:50:35

apply tests: separate common patch hunks Move the commonly-used patch hunks into a single constant location. This allows us to avoid re-declaring them in each test, and allows us to compose them to build a larger patch file that includes all the hunks.

702d4bec

2018-06-26T15:26:37

apply tests: use `git_iterator_foreach` for tests Use the new `git_iterator_foreach` API to validate the workdir against the expected workdir values instead of using the paired/multi iterator comparison callback. This allows us to use the `git_iterator_foreach` to validate the index as well, instead of assuming that the index and HEAD must always match.

9c34c996

2018-06-25T17:03:14

apply: handle file additions Don't attempt to read the postimage file during a file addition, simply use an empty buffer as the postimage. Also, test that we can handle file additions.

3b5378c5

2018-06-25T16:27:06

apply: handle file deletions If the file was deleted in the postimage, do not attempt to update the target. Instead, ignore it and simply allow it to stay removed in our computed postimage. Also, test that we can handle file deletions.

af3287f8

2018-06-22T19:27:19

apply: test `git_apply` with a parsed patch Ensure that we can apply a simple patch to the working directory when we have parsed it from a patch file.

ff296b71

2018-03-19T19:50:52

apply: test `git_apply` application to a workdir Introduce a standard test applying a diff to a working directory with no complications.

02b1083a

2018-01-28T23:25:07

apply: introduce `git_apply_tree` Introduce `git_apply_tree`, which will apply a `git_diff` to a given `git_tree`, allowing an in-memory patch application for a repository.

2b12dcf6

2018-03-19T19:45:11

iterator: optionally hash filesystem iterators Optionally hash the contents of files encountered in the filesystem or working directory iterators. This is not expected to be used in production code paths, but may allow us to simplify some test contexts. For working directory iterators, apply filters as appropriate, since we have the context able to do it.

b5ae83bf

2018-10-31T08:47:10

Merge pull request #4860 from tiennou/ci/macos-leaks CI: Fix macOS leak detection

0e69485e

2018-10-23T20:34:47

clar: provide a way to run some shell before exiting

623647af

2018-10-26T12:33:59

Merge pull request #4864 from pks-t/pks/object-parse-fixes Object parse fixes

7655b2d8

2018-10-19T10:29:19

commit: fix reading out of bounds when parsing encoding The commit message encoding is currently being parsed by the `git__prefixcmp` function. As this function does not accept a buffer length, it will happily skip over a buffer's end if it is not `NUL` terminated. Fix the issue by using `git__prefixncmp` instead. Add a test that verifies that we are unable to parse the encoding field if it's cut off by the supplied buffer length.

c2e3d8ef

2018-10-25T12:01:18

tests: add tests that exercise commit parsing We currently do not have any test suites dedicated to parsing commits from their raw representations. Add one based on `git_object__from_raw` to be able to test special cases more easily.

ee11d47e

2018-10-19T09:47:50

tag: fix out of bounds read when searching for tag message When parsing tags, we skip all unknown fields that appear before the tag message. This skipping is done by using a plain `strstr(buffer, "\n\n")` to search for the two newlines that separate tag fields from tag message. As it is not possible to supply a buffer length to `strstr`, this call may skip over the buffer's end and thus result in an out of bounds read. As `strstr` may return a pointer that is out of bounds, the following computation of `buffer_end - buffer` will overflow and result in an allocation of an invalid length. Fix the issue by using `git__memmem` instead. Add a test that verifies parsing the tag fails not due to the allocation failure but due to the tag having no message.

4c738e56

2018-10-19T09:44:14

tests: add tests that exercise tag parsing While the tests in object::tag::read exercises reading and parsing valid tags from the ODB, they barely try to verify that the parser fails in a sane way when parsing invalid tags. Create a new test suite object::tag::parse that directly exercise the parser by using `git_object__from_raw` and add various tests for valid and invalid tags.

83e8a6b3

2018-10-18T16:08:46

util: provide `git__memmem` function Unfortunately, neither the `memmem` nor the `strnstr` functions are part of any C standard but are merely extensions of C that are implemented by e.g. glibc. Thus, there is no standardized way to search for a string in a block of memory with a limited size, and using `strstr` is to be considered unsafe in case where the buffer has not been sanitized. In fact, there are some uses of `strstr` in exactly that unsafe way in our codebase. Provide a new function `git__memmem` that implements the `memmem` semantics. That is in a given haystack of `n` bytes, search for the occurrence of a byte sequence of `m` bytes and return a pointer to the first occurrence. The implementation chosen is the "Not So Naive" algorithm from [1]. It was chosen as the implementation is comparably simple while still being reasonably efficient in most cases. Preprocessing happens in constant time and space, searching has a time complexity of O(n*m) with a slightly sub-linear average case. [1]: http://www-igm.univ-mlv.fr/~lecroq/string/

bea65980

2018-10-25T11:21:14

Merge pull request #4851 from pks-t/pks/strtol-removal strtol removal

2e34efaa

2018-10-21T13:10:06

buf::oom tests: use custom allocator for oom failures Create a custom allocator for the `buf::oom` tests that will fail with out-of-memory errors in predictable ways. We were previously trying to guess the way that various allocators on various platforms would fail in a way such that `malloc`/`realloc` would return `NULL` (instead of aborting the application, or appearing suspicious to various instrumentation or static code analysis tools like valgrind.) Introduce a fake `malloc` and `realloc` that will return `NULL` on allocations requesting more than 100 bytes. Otherwise, we proxy to the default allocator. (It's important to use the _default_ allocator, not just call `malloc`, since the default allocator on Windows CI builds may be the debugging C runtime allocators which would not be compatible with a standard `malloc`.)

415a8ae9

2018-09-13T13:27:07

tests: don't run buf::oom on 32-bit systems On a 32-bit Linux systems, the value large enough to make malloc guarantee a failure is also large enough that valgrind considers it "fishy". Skip this test on those systems entirely.

7c791f3d

2018-10-20T20:25:51

Merge pull request #4852 from libgit2/ethomson/unc_paths Win32 path canonicalization refactoring

6cc14ae3

2018-10-20T20:22:04

Merge pull request #4840 from libgit2/cmn/validity-tree-from-unowned-index Check object existence when creating a tree from an index

a2f9f94b

2018-10-20T20:18:04

Merge branch 'issue-4203'

c79e6081

2018-10-20T19:08:16

checkout: fix test fixture missing objects The testrepo test fixture has an index file that's damaged, missing an object. The index previously had an entry of `src/index.c` with id 3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in the repository. This commit adds an object to the repository and updates the index to use that existing blob. Similarly, the index has an entry for `readme` with an id of 97328ac7e3bd0bcd3900cb3e7a624d71dd0df888. This can be restored from other test repositories. With these fixed, now the write tree from index tests can pass since they validate object existence.

ea19efc1

2018-10-18T15:08:56

util: fix out of bounds read in error message When an integer that is parsed with `git__strntol32` is too big to fit into an int32, we will generate an error message that includes the actual string that failed to parse. This does not acknowledge the fact that the string may either not be NUL terminated or alternative include additional characters after the number that is to be parsed. We may thus end up printing characters into the buffer that aren't the number or, worse, read out of bounds. Fix the issue by utilizing the `endptr` that was set by `git__strntol64`. This pointer is guaranteed to be set to the first character following the number, and we can thus use it to compute the width of the number that shall be printed. Create a test to verify that we correctly truncate the number.

16fd9ba9

2018-10-17T11:34:38

win32: more tests for `git_win32_remove_path`

b2e85f98

2018-10-17T08:48:43

win32: rename `git_win32__canonicalize_path` The internal API `git_win32__canonicalize_path` is far, far too easily confused with the internal API `git_win32_path_canonicalize`. The former removes the namespace prefix from a path (eg, given `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given `\\?\UNC\server\share`, it returns `\\server\share`). As such, rename it to `git_win32_path_remove_namespace`. `git_win32_path_canonicalize` remains unchanged.

39087ab8

2018-10-18T12:11:33

tests: core::strtol: test for some more edge-cases Some edge cases were currently completely untested, e.g. parsing numbers greater than INT64_{MIN,MAX}, truncating buffers by length and invalid characters. Add tests to verify that the system under test performs as expected.

8d7fa88a

2018-10-18T12:04:07

util: remove `git__strtol32` The function `git__strtol32` can easily be misused when untrusted data is passed to it that may not have been sanitized with trailing `NUL` bytes. As all usages of this function have now been removed, we can remove this function altogether to avoid future misuse of it.

68deb2cc

2018-10-18T11:37:10

util: remove unsafe `git__strtol64` function The function `git__strtol64` does not take a maximum buffer length as parameter. This has led to some unsafe usages of this function, and as such we may consider it as being unsafe to use. As we have now eradicated all usages of this function, let's remove it completely to avoid future misuse.

1cbc9604

2018-09-28T10:57:50

config: add failing test for no newline after section header

814e7acb

2018-10-12T12:38:06

Merge pull request #4842 from nelhage/fuzz-config-memory config: Port config_file_fuzzer to the new in-memory backend.

2d449a11

2018-10-09T02:42:14

config: Refactor `git_config_backend_from_string` to take a length

fbc0dcda

2018-10-08T13:01:23

index: add failing test for writing an invalid tree from an unowned index When the index does not belong to any repository, we do not do any checks of the target id going in as we cannot verify that it exists. When we then write it out to a repository as a tree, we fail to perform the object existance and type-matching check that we do in other code-paths. This leads to being able to write trees which point to non-existent blobs even with strict object creation enabled.

838a2f29

2018-10-07T12:00:48

Merge pull request #4828 from csware/git_futils_rmdir_r_failing Add some more tests for git_futils_rmdir_r and some cleanup

0cd976c8

2018-10-07T12:00:06

Merge pull request #4830 from pks-t/pks/diff-stats-rename-common diff_stats: use git's formatting of renames with common directories

a8d447f6

2018-10-05T20:13:34

Merge pull request #4837 from pks-t/cmn/reject-option-submodule-url-path submodule: ignore path and url attributes if they look like options

ce8803a2

2018-10-05T20:03:38

Merge pull request #4836 from pks-t/pks/smart-packets Smart packet security fixes

84d6f439

2018-10-05T19:53:22

Merge pull request #4832 from pks-t/pks/config-includes-null-deref config_file: properly ignore includes without "path" value

4e0bdaa8

2018-10-05T11:42:00

submodule: add failing test for option-injection protection in url and path

ad273718

2018-10-04T10:32:07

tests: sanitize file hierarchy after running rmdir tests Currently, we do not clean up after ourselves after tests in core::rmdir have created new files in the directory hierarchy. This may leave stale files and/or directories after having run tests, confusing subsequent tests that expect a pristine test environment. Most importantly, it may cause the test initialization to fail which expects being able to re-create the testing hierarchy before each test in case where another test hasn't cleaned up after itself. Fix the issue by adding a cleanup function that removes the temporary testing hierarchy after each test if it still exists.

e886ab46

2018-10-02T19:50:29

tests: Add some more tests for git_futils_rmdir_r Signed-off-by: Sven Strickroth <email@cs-ware.de>

d06d4220

2018-10-05T10:56:02

config_file: properly ignore includes without "path" value In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810.

bf662f7c

2018-10-05T10:55:29

tests: always unlink created config files While our tests in config::include create a plethora of configuration files, most of them do not get removed at the end of each test. This can cause weird interactions with tests that are being run at a later stage if these later tests try to create files or directories with the same name as any of the created configuration files. Fix the issue by unlinking all created files at the end of these tests.

dbb4a586

2018-10-05T10:27:33

tests: fix warning for implicit conversion of integer to pointer GCC warns by default when implicitly converting integers to pointers or the other way round, and commit fa48d2ea7 (vector: do not malloc 0-length vectors on dup, 2018-09-26) introduced such an implicit conversion into our vector tests. While this is totally fine in this test, as the pointer's value is never being used in the first place, we can trivially avoid the warning by instead just inserting a pointer for a variable allocated on the stack into the vector.

3f096ca5

2018-10-04T13:03:25

Fix comment style and update test code

e5090ee3

2018-10-04T11:19:28

diff_stats: use git's formatting of renames with common directories 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.

3148efd2

2018-10-04T11:13:57

tests: verify diff stats with renames in subdirectory 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.

0b3dfbf4

2018-08-09T11:13:59

smart_pkt: reorder and rename parameters of `git_pkt_parse_line` The parameters of the `git_pkt_parse_line` function are quite confusing. First, there is no real indicator what the `out` parameter is actually all about, and it's not really clear what the `bufflen` parameter refers to. Reorder and rename the parameters to make this more obvious.

a9f1ca09

2018-08-09T11:01:00

smart_pkt: fix buffer overflow when parsing "ok" packets There are two different buffer overflows present when parsing "ok" packets. First, we never verify whether the line already ends after "ok", but directly go ahead and also try to skip the expected space after "ok". Second, we then go ahead and use `strchr` to scan for the terminating newline character. But in case where the line isn't terminated correctly, this can overflow the line buffer. Fix the issues by using `git__prefixncmp` to check for the "ok " prefix and only checking for a trailing '\n' instead of using `memchr`. This also fixes the issue of us always requiring a trailing '\n'. Reported by oss-fuzz, issue 9749: Crash Type: Heap-buffer-overflow READ {*} Crash Address: 0x6310000389c0 Crash State: ok_pkt git_pkt_parse_line git_smart__store_refs Sanitizer: address (ASAN)

bc349045

2018-08-09T10:38:10

smart_pkt: fix buffer overflow when parsing "ACK" packets We are being quite lenient when parsing "ACK" packets. First, we didn't correctly verify that we're not overrunning the provided buffer length, which we fix here by using `git__prefixncmp` instead of `git__prefixcmp`. Second, we do not verify that the actual contents make any sense at all, as we simply ignore errors when parsing the ACKs OID and any unknown status strings. This may result in a parsed packet structure with invalid contents, which is being silently passed to the caller. This is being fixed by performing proper input validation and checking of return codes.

365d2720

2018-10-03T15:39:40

tests: verify parsing logic for smart packets The commits following this commit are about to introduce quite a lot of refactoring and tightening of the smart packet parser. Unfortunately, we do not yet have any tests despite our online tests that verify that our parser does not regress upon changes. This is doubly unfortunate as our online tests aren't executed by default. Add new tests that exercise the smart parsing logic directly by executing `git_pkt_parse_line`.

8ab11dd5

2018-09-30T16:40:22

Fix issue with path canonicalization for Win32 paths

1621a37d

2018-09-29T13:22:59

Merge pull request #4812 from libgit2/ethomson/ci-refactor CI: refactoring

0530d7d9

2018-09-28T18:04:23

Merge pull request #4767 from pks-t/pks/config-mem In-memory configuration

2be39cef

2018-08-10T19:38:57

config: introduce new read-only in-memory backend Now that we have abstracted away how to store and retrieve config entries, it became trivial to implement a new in-memory backend by making use of this. And thus we do so. This commit implements a new read-only in-memory backend that can parse a chunk of memory into a `git_config_backend` structure.

b944e137

2018-08-10T13:03:33

config: rename "config_file.h" to "config_backend.h" The header "config_file.h" has a list of inline-functions to access the contents of a config backend without directly messing with the struct's function pointers. While all these functions are called "git_config_file_*", they are in fact completely backend-agnostic and don't care whether it is a file or not. Rename all the function to instead be backend-agnostic versions called "git_config_backend_*" and rename the header to match.

ba1cd495

2018-09-28T11:10:49

Merge pull request #4784 from tiennou/fix/warnings Some warnings

367f6243

2018-09-28T11:04:06

Merge pull request #4803 from tiennou/fix/4802 index: release the snapshot instead of freeing the index

fa48d2ea

2018-09-26T19:15:35

vector: do not malloc 0-length vectors on dup

be4717d2

2018-09-18T12:12:06

path: fix "comparison always true" warning

e84914fd

2018-09-20T20:11:36

online::clone: free url and username before resetting Before resetting the url and username, ensure that we free them in case they were set by environment variables.

943181c2

2018-09-10T12:36:51

Revert "clar: introduce CLAR_XML option" This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8. Using clar to propagate the XML settings was a mistake.

d17e67d0

2018-09-08T18:54:21

clar: iterate errors in report_all / report_errors Instead of trying to have a clever iterator pattern that increments the error number, just iterate over errors in the report errors or report all functions as it's easier to reason about in this fashion.

thodg/libgit2/tests

tests

Log