src


Log

Author Commit Date CI Message
Edward Thomson 47dd665a 2019-11-16T15:21:56 Merge pull request #5303 from pks-t/pks/patch-path-in-body-only patch_parse: use paths from "---"/"+++" lines for binary patches
Edward Thomson cb6bc6f2 2019-11-16T15:17:54 Merge pull request #5285 from pcpthm/winhttp-308 Follow 308 redirect in WinHTTP transport
Edward Thomson 541b8fc5 2019-11-16T15:12:52 Merge pull request #5302 from tiennou/fix/p_lstat-errno fileops: correct error return on p_lstat failures when mkdir
Patrick Steinhardt de7659cc 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.
Etienne Samson 0c2b0206 2019-11-09T09:41:13 fileops: correct error return on p_lstat failures when mkdir IIRC I got a strange return once from lstat, which translated in a weird error class/message being reported. As a safety measure, enforce a -1 return in that case.
Edward Thomson 01ea911b 2019-11-06T06:04:55 Merge pull request #5299 from pks-t/pks/config-mem-snapshots config_mem: implement support for snapshots
Patrick Steinhardt 146e5bf7 2019-11-06T07:27:35 config_mem: implement support for snapshots Similar as in commit dadbb33b6 (Fix crash if snapshotting a config_snapshot, 2019-11-01), let's implement snapshots for in-memory configuration entries. As this deletes more code than it adds, it doesn't make any sense to not allow for this and allows users to treat config backends mostly the same.
Patrick Steinhardt de543e29 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.
Patrick Steinhardt 0927156a 2019-10-24T12:32:11 config_file: refactor taking entries ref to return an error code The function to take a reference to the config file's config entries currently returns the reference via return value. Due to this, it's harder than necessary to integrate into our typical coding style, as one needs to make sure that a proper error code is set before erroring out from the caller. This bites us in `config_file_delete`, where we call `goto out` directly when `config_file_entries_take` returns `NULL`, but we actually forget to set up the error code and thus return success. Fix the issue by refactoring the function to return an error code and pass the reference via an out-pointer.
Patrick Steinhardt db301087 2019-10-24T12:17:02 config_file: remove unused includes
Patrick Steinhardt c2749849 2019-10-24T12:00:11 config_file: rename function names As with the predecessing commit, this commit renames backend functions of the configuration file backend. This helps to clearly separate functionality and also to be able to see from backtraces which backend is currently in use.
Patrick Steinhardt 56b203a5 2019-10-24T12:20:27 config_file: keep reference to config entries when creating iterator When creating a configuration file iterator, then we first refresh the backend and then afterwards duplicate all refreshed configuration entries into the iterator in order to avoid seeing any concurrent modifications of the entries while iterating. The duplication of entries is not guarded, though, as we do not increase the refcount of the entries that we duplicate right now. This opens us up for a race, as another thread may concurrently refresh the repository configuration and thus swap out the current set of entries. As we didn't increase the refcount, this may lead to the entries being free'd while we iterate over them in the first thread. Fix the issue by properly handling the lifecycle of the backend's entries via `config_file_entries_take` and `git_config_entries_free`, respectively.
Patrick Steinhardt b30b04a9 2019-11-05T12:34:14 config_snapshot: rename function names The configuration snapshot backend has been extracted from the old files backend back in 2bff84ba4 (config_file: separate out read-only backend, 2019-07-26). To keep code churn manageable, the local functions weren't renamed yet and thus still have references to the old diskfile backend. Rename them accordingly to make them easier to understand.
Patrick Steinhardt 82d7a114 2019-11-05T11:18:14 Merge pull request #5293 from csware/config_snapshot-snapshot Fix crash if snapshotting a config_snapshot
romkatv 1886478d 2019-11-05T07:45:11 fix a bug introduced in 8a23597b
Edward Thomson bf2911d7 2019-11-02T07:30:32 Merge pull request #5275 from pks-t/pks/reflogs-with-newlines reflogs: fix behaviour around reflogs with newlines
Sven Strickroth dadbb33b 2019-11-01T18:55:54 Fix crash if snapshotting a config_snapshot Signed-off-by: Sven Strickroth <email@cs-ware.de>
Carlos Martín Nieto 718f24ad 2019-10-30T20:39:03 commit: verify objects exist in git_commit_with_signature There can be a significant difference between the system where we created the buffer (if at all) and when the caller provides us with the contents of a commit. Verify that the commit we are being asked to create references objects which do exist in the target repository.
Patrick Steinhardt 2a7d6de3 2019-10-29T07:52:31 Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixes patch_parse: fixes for fuzzing errors
pcpthm 3f998aee 2019-10-26T17:21:29 Follow 308 redirect in WinHTTP transport
Patrick Steinhardt a31f4c4b 2019-10-24T13:16:03 Merge pull request #5227 from ddevault/check apply: add GIT_APPLY_CHECK
Patrick Steinhardt c405f231 2019-10-24T10:26:43 Merge pull request #5264 from henkesn/refs-unlock-on-commit refs: unlock unmodified refs on transaction commit
Drew DeVault 02af1fcb 2019-09-14T14:03:36 apply: add GIT_APPLY_CHECK This adds an option which will check if a diff is applicable without actually applying it; equivalent to git apply --check.
Patrick Steinhardt 37141ff7 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.
Patrick Steinhardt 468e3ddc 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.
Patrick Steinhardt 6c6c15e9 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.
Patrick Steinhardt 223e7e43 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.
Patrick Steinhardt 7968e90f 2019-10-18T12:33:07 refdb_fs: properly parse corrupted reflogs In previous versions, libgit2 could be coerced into writing reflog messages with embedded newlines into the reflog by using `git_stash_save` with a message containing newlines. While the root cause is fixed now, it was noticed that upstream git is in fact able to read such corrupted reflog messages just fine. Make the reflog parser more lenient in order to just skip over malformatted reflog lines to bring us in line with git. This requires us to change an existing test that verified that we do indeed _fail_ to parse such logs.
Patrick Steinhardt 8532ed11 2019-10-18T12:14:19 refdb_fs: convert reflog parsing to use parser The refdb_fs code to parse the reflog currently uses a hand-rolled parser. Convert it to use our `git_parse_ctx` structure instead.
Patrick Steinhardt d8233feb 2019-10-18T09:24:14 reflog: allow adding entries with newlines in their message Currently, the reflog disallows any entries that have a message with newlines, as that would effectively break the reflog format, which may contain a single line per entry, only. Upstream git behaves a bit differently, though, especially when considering stashes: instead of rejecting any reflog entry with newlines, git will simply replace newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will create a reflog entry with "foo bar" as entry message. This commit adjusts our own logic to stop rejecting commit messages with newlines. Previously, this logic was part of `git_reflog_append`, only. There is a second place though where we add reflog entries, which is the serialization code in the filesystem refdb. As it didn't contain any sanity checks whatsoever, the refdb would have been perfectly happy to write malformatted reflog entries to the disk. This is being fixed with the same logic as for the reflog itself.
Patrick Steinhardt 28481609 2019-10-18T09:41:20 stash: refactor code that prepares commit messages
Patrick Steinhardt ca2d34a8 2019-10-18T09:06:48 stash: modernize code style of `git_stash_save` The code style of `git_stash_save` doesn't really match our current coding style. Update it to match our current policies more closely.
Patrick Steinhardt c9464bf7 2019-10-17T18:33:12 Merge pull request #5273 from dlax/parse-diff-without-extended-headers patch_parse: handle patches without extended headers
Sebastian Henke 47531f47 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.
Etienne Samson 3c5d78bd 2019-05-01T16:16:26 submodule: provide a wrapper for simple submodule clone steps
Denis Laxalde 11de594f 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.
Etienne Samson dbc17a7e 2019-09-21T08:46:08 negotiate: use GSS.framework on macOS
Etienne Samson 0eecb660 2019-10-13T13:53:18 cmake: remove extra GIT_NTLM define
Etienne Samson aa234ac0 2019-09-21T08:47:01 util: hide helper qsort code to silence unused functions warning
Patrick Steinhardt ef5a3851 2019-10-11T07:47:17 Merge pull request #5257 from henkesn/master Fix file locking on POSIX OS
Patrick Steinhardt 1f9b4970 2019-10-11T07:44:10 Merge pull request #5260 from pks-t/pks/cmake3 cmake: update minimum CMake version to v3.5.1
Sebastian Henke 3335a034 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.
Patrick Steinhardt 6716e2f3 2019-10-10T12:34:45 Merge pull request #5248 from dlax/parse-patch-empty-files patch_parse: handle patches with new empty files
Patrick Steinhardt ebabb88f 2019-10-10T09:25:32 cmake: update minimum CMake version to v3.5.1 Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11, 2017-09-06), we have bumped the minimum CMake version to require at least v2.8.11. The main hold-backs back then were distributions like RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6 has CMake v3.6.1 available via the EPEL6 repository, and thus it seems fair to upgrade to a more recent version. Going through repology [1], one can see that all supported mainstream distributions do in fact have CMake 3 available. Going through the list, the minimum version that is supported by all mainstream distros is in fact v3.5.1: - CentOS 6 via EPEL6: 3.6.1 - Debian Oldstable: 3.7.2 - Fedora 26: 3.8.2 - OpenMandriva 3.x: 3.5.1 - Slackware 14.2: 3.5.2 - Ubuntu 16.04: 3.5.1 Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and remove all the version CMake checks that aren't required anymore. [1]: https://repology.org/project/cmake/versions
Patrick Steinhardt f04a58b0 2019-10-03T12:55:48 Merge pull request #4445 from tiennou/shallow/dry-commit-parsing DRY commit parsing
Patrick Steinhardt 5cf17e0f 2019-10-03T09:39:42 commit_list: store in/out-degrees as uint16_t The commit list's in- and out-degrees are currently stored as `unsigned short`. When assigning it the value of `git_array_size`, which returns an `size_t`, this generates a warning on some Win32 platforms due to loosing precision. We could just cast the returned value of `git_array_size`, which would work fine for 99.99% of all cases as commits typically have less than 2^16 parents. For crafted commits though we might end up with a wrong value, and thus we should definitely check whether the array size actually fits into the field. To ease the check, let's convert the fields to store the degrees as `uint16_t`. We shouldn't rely on such unspecific types anyway, as it may lead to different behaviour across platforms. Furthermore, this commit introduces a new `git__is_uint16` function to check whether it actually fits -- if not, we return an error.
Etienne Samson 5988cf34 2017-12-15T18:11:51 commit_list: unify commit information parsing
Etienne Samson 1c847a6a 2018-10-25T19:40:19 commit: generic parse mechanism This allows us to pick which data from a commit we're interested in. This will be used by the revwalk code, which is only interested in parents' and committer data.
Edward Thomson 63307cba 2019-09-28T17:32:18 Merge pull request #5226 from pks-t/pks/regexp-api regexp: implement a new regular expression API
Denis Laxalde b61810bf 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.
Patrick Steinhardt 70325370 2019-09-27T11:16:02 Merge pull request #5106 from tiennou/fix/ref-api-fixes git_refdb API fixes
Sven Strickroth 452b7f8f 2019-09-25T20:29:21 Don't use enum for flags Using an `enum` causes trouble when used with C++ as bitwise operations are not possible w/o casting (e.g., `opts.flags &= ~GIT_BLOB_FILTER_CHECK_FOR_BINARY;` is invalid as there is no `&=` operator for `enum`). Signed-off-by: Sven Strickroth <email@cs-ware.de>
Edward Thomson 3c1aa232 2019-09-21T16:09:00 Merge pull request #5232 from pks-t/pks/buffer-ensure-size-oom buffer: fix writes into out-of-memory buffers
Patrick Steinhardt f585b129 2019-09-12T14:29:28 posix: remove superseded POSIX regex wrappers The old POSIX regex wrappers have been superseded by our own regexp API that provides a higher-level abstraction. Remove the POSIX wrappers in favor of the new one.
Patrick Steinhardt 7aacf027 2019-09-13T08:55:33 global: convert all users of POSIX regex to use our new regexp API The old POSIX regex API has been superseded by our new regexp API. Convert all users to make use of the new one.
Patrick Steinhardt d77378eb 2019-09-13T08:54:26 regexp: implement new regular expression API We currently support a set of different regular expression backends with PCRE, PCRE2, regcomp(3P) and regcomp_l(3). The current implementation of this is done via a simple POSIX wrapper that either directly uses supplied functions or that is a very small wrapper. To support PCRE and PCRE2, we use their provided <pcreposix.h> and <pcre2posix.h> wrappers. These wrappers are implemented in such a way that the accompanying libraries pcre-posix and pcre2-posix provide the same symbols as the libc ones, namely regcomp(3P) et al. This works out on some systems just fine, most importantly on glibc-based ones, where the regular expression functions are implemented as weak aliases and thus get overridden by linking in the pcre{,2}-posix library. On other systems we depend on the linking order of libc and pcre library, and as libc always comes first we will end up with the functions of the libc implementation. As a result, we may use the structures `regex_t` and `regmatch_t` declared by <pcre{,2}posix.h>, but use functions defined by the libc, leading to segfaults. The issue is not easily solvable. Somed distributions like Debian have resolved this by patching PCRE and PCRE2 to carry custom prefixes to all the POSIX function wrappers. But this is not supported by upstream and thus inherently unportable between distributions. We could instead try to modify linking order, but this starts becoming fragile and will not work e.g. when libgit2 is loaded via dlopen(3P) or similar ways. In the end, this means that we simply cannot use the POSIX wrappers provided by the PCRE libraries at all. Thus, this commit introduces a new regular expression API. The new API is on a tad higher level than the previous POSIX abstraction layer, as it tries to abstract away any non-portable flags like e.g. REG_EXTENDED, which has no equivalents in all of our supported backends. As there are no users of POSIX regular expressions that do _not_ reguest REG_EXTENDED this is fine to be abstracted away, though. Due to the API being higher-level than before, it should generally be a tad easier to use than the previous one. Note: ideally, the new API would've been called `git_regex_foobar` with a file "regex.h" and "regex.c". Unfortunately, this is currently impossible to implement due to naming clashes between the then-existing "regex.h" and <regex.h> provided by the libc. As we add the source directory of libgit2 to the header search path, an include of <regex.h> would always find our own "regex.h". Thus, we have to take the bitter pill of adding one more character to all the functions to disambiguate the includes. To improve guarantees around cross-backend compatibility, this commit also brings along an improved regular expression test suite core::regexp.
Patrick Steinhardt 174b7a32 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.
Patrick Steinhardt 208f1d7a 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.
Patrick Steinhardt 3e8a17b0 2019-09-21T15:18:42 buffer: fix memory leak if unable to grow buffer If growing a buffer fails, we set its pointer to the static `git_buf__oom` structure. While we correctly free the old pointer if `git__malloc` returned an error, we do not free it if there was an integer overflow while calculating the new allocation size. Fix this issue by freeing the pointer to plug the memory leak.
Etienne Samson 49a3289e 2019-09-21T08:25:23 cred: add missing private header in GSSAPI block Should have been part of 8bf0f7eb26c65b2b937b1f40a384b9b269b0b76d
Patrick Steinhardt aa407ca3 2019-09-19T13:23:59 Merge pull request #5206 from tiennou/cmake/pkgconfig-building CMake pkg-config modulification
Etienne Samson 564b3ffc 2019-08-17T12:34:59 cmake: add missing requires to the .pc file
Etienne Samson d80d9d56 2019-08-17T12:17:21 cmake: streamline *.pc file handling via a module
Etienne Samson 8bf0f7eb 2019-09-09T13:00:27 cred: separate public interface from low-level details
Patrick Steinhardt 5d8a4659 2019-09-13T10:31:49 Merge pull request #5195 from tiennou/fix/commitish-smart-push smart: use push_glob instead of manual filtering
Laurence McGlashan dde6d9c7 2019-09-10T17:09:57 open:move all cleanup code to cleanup label in git_repository_open_ext
Laurence McGlashan b545be3d 2019-09-10T11:14:36 open:fix memory leak when passing NULL to git_repository_open_ext
Edward Thomson c3a7892f 2019-09-09T13:10:24 Merge pull request #5209 from mkostyuk/apply-wrong-patch apply: Fix a patch corruption related to EOFNL handling
Edward Thomson 17d6cd45 2019-09-09T13:06:22 Merge pull request #5210 from buddyspike/master ignore: correct handling of nested rules overriding wild card unignore
Edward Thomson 4d3392dd 2019-09-09T13:03:42 Merge pull request #5214 from pks-t/pks/diff-iterator-allocation-fixes Memory allocation fixes for diff generator
Edward Thomson 39028eb6 2019-09-09T13:00:53 Merge pull request #5212 from libgit2/ethomson/creds_for_scheme Use an HTTP scheme that supports the given credentials
Etienne Samson 8c142241 2019-06-14T08:20:05 refdb: make sure to remove packed refs first This fixes part of the issue where, given a concurrent `git pack-refs`, a ref lookup could return an old, vestigial value from the packed file, as the valid loose one would have been deleted.
Etienne Samson 171116e7 2019-06-14T06:50:41 refdb: repurpose filesystem prune function
Etienne Samson 8fd855fd 2019-02-02T19:00:51 refdb: reorder parameters for consistency
Etienne Samson 9b25cf15 2019-02-02T19:00:49 refdb: fix packed_delete clobbering some errors In the case of a failed lookup, we'd paper over that by writing back the packed-refs successfully.
Etienne Samson 0a88c83d 2019-02-02T19:00:47 refdb: make low-level deletion helpers explicit
Etienne Samson baf411e7 2019-02-02T19:00:45 refdb: ensure all mandatory functions are provided at setup time
Etienne Samson c2cf9844 2019-02-02T19:00:43 refdb: check the version of the backend we're about to set
Etienne Samson 8db9fd3b 2019-02-02T19:00:41 refdb: documentation
buddyspike a7b4b639 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
Edward Thomson 5fc27aac 2019-08-27T13:38:08 Merge pull request #5208 from mkostyuk/apply-removed-new-file apply: git_apply_to_tree fails to apply patches that add new files
Edward Thomson 6de48085 2019-08-27T11:29:24 Merge pull request #5189 from libgit2/ethomson/attrs_from_head Optionally read `.gitattributes` from HEAD
Edward Thomson aaa48d06 2019-08-27T11:26:50 Merge pull request #5196 from pks-t/pks/config-include-onbranch config: implement "onbranch" conditional
Patrick Steinhardt 699de9c5 2019-08-27T10:36:17 iterator: remove duplicate memset When allocating new tree iterator frames, we zero out the allocated memory twice. Remove one of the `memset` calls.
Patrick Steinhardt 9ca7a60e 2019-08-27T10:36:20 iterator: avoid leaving partially initialized frame on stack When allocating tree iterator entries, we use GIT_ERROR_ALLOC_CHECK` to check whether the allocation has failed. The macro will cause the function to immediately return, though, leaving behind a partially initialized iterator frame. Fix the issue by manually checking for memory allocation errors and using `goto done` in case of an error, popping the iterator frame.
Patrick Steinhardt fe241071 2019-08-27T10:36:19 diff_generate: detect memory allocation errors when preparing opts When preparing options for the two iterators that are about to be diffed, we allocate a common prefix for both iterators depending on the options passed by the user. We do not check whether the allocation was successful, though. In fact, this isn't much of a problem, as using a `NULL` prefix is perfectly fine. But in the end, we probably want to detect that the system doesn't have any memory left, as we're unlikely to be able to continue afterwards anyway. While the issue is being fixed in the newly created function `diff_prepare_iterator_opts`, it has been previously existing in the previous macro `DIFF_FROM_ITERATORS` already.
Patrick Steinhardt 8a23597b 2019-08-27T10:36:18 diff_generate: refactor `DIFF_FROM_ITERATORS` macro of doom While the `DIFF_FROM_ITERATORS` does make it shorter to implement the various `git_diff_foo_to_bar` functions, it is a complex and unreadable beast that implicitly assumes certain local variable names. This is not something desirable to have at all and obstructs understanding and more importantly debugging the code by quite a bit. The `DIFF_FROM_ITERATORS` macro basically removed the burden of having to derive the options for both iterators from a pair of iterator flags and the diff options. This patch introduces a new function that does the that exact and refactors all callers to manage the iterators by themselves. As we potentially need to allocate a shared prefix for the iterator, we need to tell the caller to allocate that prefix as soon as the options aren't required anymore. Thus, the function has a `char **prefix` out pointer that will get set to the allocated string and subsequently be free'd by the caller. While this patch increases the line count, I personally deem this to an acceptable tradeoff for increased readbiblity.
Edward Thomson 4e20c7b1 2019-08-25T22:11:39 Merge pull request #5213 from boardwalk/dskorupski/fix_include_case Fix include casing for case-sensitive filesystems.
Dan Skorupski 44d5e47d 2019-08-24T10:39:56 Fix include casing for case-sensitive filesystems.
Ian Hattendorf 4de51f9e 2019-08-23T16:05:28 http: ensure the scheme supports the credentials When a server responds with multiple scheme support - for example, Negotiate and NTLM are commonly used together - we need to ensure that we choose a scheme that supports the credentials.
Edward Thomson 60319788 2019-08-23T09:58:15 Merge pull request #5054 from tniessen/util-use-64-bit-timer util: use 64 bit timer on Windows
Etienne Samson 53f51c60 2019-08-21T19:48:05 smart: implement by-date insertion when revwalking
Etienne Samson 4b91f058 2019-08-21T19:43:06 revwalk: expose more ways of scheduling commits Before we can tweak the revwalk to be more efficent when negotiating, we need to add an "insertion mode" option. Since there's already an implicit set of those, make it visible, at least privately.
Patrick Steinhardt 8cbef12d 2019-08-08T11:52:54 util: do not perform allocations in insertsort Our hand-rolled fallback sorting function `git__insertsort_r` does an in-place sort of the given array. As elements may not necessarily be pointers, it needs a way of swapping two values of arbitrary size, which is currently implemented by allocating a temporary buffer of the element's size. This is problematic, though, as the emulated `qsort` interface doesn't provide any return values and thus cannot signal an error if allocation of that temporary buffer has failed. Convert the function to swap via a temporary buffer allocated on the stack. Like this, it can `memcpy` contents of both elements in small batches without requiring a heap allocation. The buffer size has been chosen such that in most cases, a single iteration of copying will suffice. Most importantly, it can fully contain `git_oid` structures and pointers. Add a bunch of tests for the `git__qsort_r` interface to verify nothing breaks. Furthermore, this removes the declaration of `git__insertsort_r` and makes it static as it is not used anywhere else.
Patrick Steinhardt f3b3e543 2019-08-08T11:34:01 xdiff: catch memory allocation errors The xdiff code contains multiple call sites where the results of `xdl_malloc` are not being checked for memory allocation errors. Add checks to fix possible segfaults due to `NULL` pointer accesses.
Patrick Steinhardt c2dd895a 2019-08-08T10:47:29 transports: http: check for memory allocation failures When allocating a chunk that is used to write to HTTP streams, we do not check for memory allocation errors. This may lead us to write to a `NULL` pointer and thus cause a segfault. Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.
Patrick Steinhardt 08699541 2019-08-08T10:46:42 trailer: check for memory allocation errors The "trailer.c" code has been copied mostly verbatim from git.git with minor adjustments, only. As git.git's `xmalloc` function, which aborts on memory allocation errors, has been swapped out for `git_malloc`, which doesn't abort, we may inadvertently access `NULL` pointers. Add checks to fix this.
Patrick Steinhardt 8c7d9761 2019-08-08T10:45:12 posix: fix direct use of `malloc` In "posix.c" there are multiple callsites which execute `malloc` instead of `git__malloc`. Thus, users of library are not able to track these allocations with a custom allocator. Convert these call sites to use `git__malloc` instead.
Patrick Steinhardt a477bff1 2019-08-08T10:44:57 indexer: catch OOM when adding expected OIDs When adding OIDs to the indexer's map of yet-to-be-seen OIDs to verify that packfiles are complete, we do so by first allocating a new OID and then calling `git_oidmap_set` on it. There was no check for memory allocation errors in place, though, leading to possible segfaults due to trying to copy data to a `NULL` pointer. Verify the result of `git__malloc` with `GIT_ERROR_CHECK_ALLOC` to fix the issue.
Patrick Steinhardt d4fe402b 2019-08-08T10:36:33 merge: check return value of `git_commit_list_insert` The function `git_commit_list_insert` dynamically allocates memory and may thus fail to insert a given commit, but we didn't check for that in several places in "merge.c". Convert surrounding functions to return error codes and check whether `git_commit_list_insert` was successful, returning an error if not.