summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | | config_file: refactor taking entries ref to return an error codePatrick Steinhardt2019-11-051-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | config_file: remove unused includesPatrick Steinhardt2019-11-051-6/+0
| | |
* | | config_file: rename function namesPatrick Steinhardt2019-11-051-58/+63
| | | | | | | | | | | | | | | | | | | | | 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.
* | | config_snapshot: rename function namesPatrick Steinhardt2019-11-051-22/+22
| |/ |/| | | | | | | | | | | | | 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.
* | Merge pull request #5293 from csware/config_snapshot-snapshotPatrick Steinhardt2019-11-051-0/+1
|\ \ | | | | | | Fix crash if snapshotting a config_snapshot
| * | Fix crash if snapshotting a config_snapshotSven Strickroth2019-11-011-0/+1
| | | | | | | | | | | | Signed-off-by: Sven Strickroth <email@cs-ware.de>
* | | fix a bug introduced in 8a23597bromkatv2019-11-051-1/+1
| | |
* | | Merge pull request #5275 from pks-t/pks/reflogs-with-newlinesEdward Thomson2019-11-025-112/+96
|\ \ \ | | | | | | | | reflogs: fix behaviour around reflogs with newlines
| * | | refdb_fs: properly parse corrupted reflogsPatrick Steinhardt2019-10-181-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | refdb_fs: convert reflog parsing to use parserPatrick Steinhardt2019-10-183-44/+42
| | | | | | | | | | | | | | | | | | | | The refdb_fs code to parse the reflog currently uses a hand-rolled parser. Convert it to use our `git_parse_ctx` structure instead.
| * | | reflog: allow adding entries with newlines in their messagePatrick Steinhardt2019-10-182-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | stash: refactor code that prepares commit messagesPatrick Steinhardt2019-10-181-18/+15
| | | |
| * | | stash: modernize code style of `git_stash_save`Patrick Steinhardt2019-10-181-32/+15
| | | | | | | | | | | | | | | | | | | | The code style of `git_stash_save` doesn't really match our current coding style. Update it to match our current policies more closely.
* | | | commit: verify objects exist in git_commit_with_signaturecmn/create-with-signature-verificationCarlos Martín Nieto2019-10-301-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixesPatrick Steinhardt2019-10-292-7/+62
|\ \ \ \ | |_|_|/ |/| | | patch_parse: fixes for fuzzing errors
| * | | patch_parse: detect overflow when calculating old/new line positionPatrick Steinhardt2019-10-212-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | patch_parse: fix out-of-bounds read with No-NL linesPatrick Steinhardt2019-10-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | patch_parse: reject empty path namesPatrick Steinhardt2019-10-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | patch_parse: reject patches with multiple old/new pathsPatrick Steinhardt2019-10-191-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #5227 from ddevault/checkPatrick Steinhardt2019-10-241-3/+7
|\ \ \ \ | | | | | | | | | | apply: add GIT_APPLY_CHECK
| * | | | apply: add GIT_APPLY_CHECKDrew DeVault2019-10-221-3/+7
| |/ / / | | | | | | | | | | | | | | | | This adds an option which will check if a diff is applicable without actually applying it; equivalent to git apply --check.
* | | | Merge pull request #5264 from henkesn/refs-unlock-on-commitPatrick Steinhardt2019-10-241-1/+7
|\ \ \ \ | |/ / / |/| | | refs: unlock unmodified refs on transaction commit
| * | | refs: unlock unmodified refs on transaction commitSebastian Henke2019-10-171-1/+7
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #5273 from dlax/parse-diff-without-extended-headersPatrick Steinhardt2019-10-171-0/+1
|\ \ \ | | | | | | | | patch_parse: handle patches without extended headers
| * | | patch_parse: handle patches without extended headersDenis Laxalde2019-10-161-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | submodule: provide a wrapper for simple submodule clone stepsEtienne Samson2019-10-173-3/+85
| | |
* | | negotiate: use GSS.framework on macOSEtienne Samson2019-10-134-11/+10
| | |
* | | cmake: remove extra GIT_NTLM defineEtienne Samson2019-10-131-2/+1
| | |
* | | util: hide helper qsort code to silence unused functions warningEtienne Samson2019-10-131-0/+5
|/ /
* | Merge pull request #5257 from henkesn/masterPatrick Steinhardt2019-10-117-19/+15
|\ \ | | | | | | Fix file locking on POSIX OS
| * | refs: fix locks getting forcibly removedSebastian Henke2019-10-107-19/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #5260 from pks-t/pks/cmake3Patrick Steinhardt2019-10-111-10/+2
|\ \ \ | | | | | | | | cmake: update minimum CMake version to v3.5.1
| * | | cmake: update minimum CMake version to v3.5.1Patrick Steinhardt2019-10-101-10/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge pull request #5248 from dlax/parse-patch-empty-filesPatrick Steinhardt2019-10-101-0/+1
|\ \ \ | |/ / |/| | patch_parse: handle patches with new empty files
| * | patch_parse: handle patches with new empty filesDenis Laxalde2019-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #4445 from tiennou/shallow/dry-commit-parsingPatrick Steinhardt2019-10-035-89/+76
|\ \ \ | | | | | | | | DRY commit parsing
| * | | commit_list: store in/out-degrees as uint16_tPatrick Steinhardt2019-10-033-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | commit_list: unify commit information parsingEtienne Samson2019-10-031-77/+23
| | | |
| * | | commit: generic parse mechanismEtienne Samson2019-10-032-11/+39
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #5226 from pks-t/pks/regexp-apiEdward Thomson2019-09-2811-177/+384
|\ \ \ \ | |_|/ / |/| | | regexp: implement a new regular expression API
| * | | posix: remove superseded POSIX regex wrappersPatrick Steinhardt2019-09-214-96/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | global: convert all users of POSIX regex to use our new regexp APIPatrick Steinhardt2019-09-215-81/+66
| | | | | | | | | | | | | | | | | | | | The old POSIX regex API has been superseded by our new regexp API. Convert all users to make use of the new one.
| * | | regexp: implement new regular expression APIPatrick Steinhardt2019-09-212-0/+318
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #5106 from tiennou/fix/ref-api-fixesPatrick Steinhardt2019-09-272-45/+101
|\ \ \ \ | |_|_|/ |/| | | git_refdb API fixes
| * | | refdb: make sure to remove packed refs firstEtienne Samson2019-09-051-10/+24
| | | | | | | | | | | | | | | | | | | | 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.
| * | | refdb: repurpose filesystem prune functionEtienne Samson2019-09-051-6/+6
| | | |
| * | | refdb: reorder parameters for consistencyEtienne Samson2019-09-051-9/+10
| | | |
| * | | refdb: fix packed_delete clobbering some errorsEtienne Samson2019-09-051-5/+10
| | | | | | | | | | | | | | | | | | | | In the case of a failed lookup, we'd paper over that by writing back the packed-refs successfully.
| * | | refdb: make low-level deletion helpers explicitEtienne Samson2019-09-051-23/+47
| | | |
| * | | refdb: ensure all mandatory functions are provided at setup timeEtienne Samson2019-09-051-0/+10
| | | |
View Lorry Controller Status