- 02 May, 2019 10 commits
-
-
Drew DeVault committed
-
Add a test that verifies that we are able to parse patches which add a new file that has spaces in its path.
Erik Aigner committed -
The diff header format is a strange beast in that it is inherently unparseable in an unambiguous way. While parsing a/file.txt b/file.txt is obvious and trivially doable, parsing a diff header of a/file b/file ab.txt b/file b/file ab.txt is not (but in fact valid and created by git.git). Due to that, we have relaxed our diff header parser in commit 80226b5f (patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so that we started to bail out when seeing diff headers with spaces in their file names. Instead, we try to use the "---" and "+++" lines, which are unambiguous. In some cases, though, we neither have a useable file name from the header nor from the "---" or "+++" lines. This is the case when we have a deletion or addition of a file with spaces: the header is unparseable and the other lines will simply show "/dev/null". This trips our parsing logic when we try to extract the prefix (the "a/" part) that is being used in the path line, where we unconditionally try to dereference a NULL pointer in such a scenario. We can fix this by simply not trying to parse the prefix in cases where we have no useable path name. That'd leave the parsed patch without either `old_prefix` or `new_prefix` populated. But in fact such cases are already handled by users of the patch object, which simply opt to use the default prefixes in that case.
Patrick Steinhardt committed -
Patrick Steinhardt committed
-
Steven King Jr committed
-
Steven King Jr committed
-
Matching on the prefix of a negated pattern was triggering false negatives on siblings of that pattern. e.g. Given the .gitignore: dir/* !dir/sub1/sub2/** The path `dir/a.text` would not be ignored.
Steve King Jr committed -
When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored
Tyler Ang-Wanek committed -
This change fixes a mostly theoretical memory leak in got_odb_new() that can only manifest if git_cache_init() fails due to running out of memory or not being able to acquire its lock.
lhchavez committed -
This change frees a copy of a cached object in odb_otype_fast().
lhchavez committed
-
- 14 Feb, 2019 10 commits
-
-
Release v0.28.1
Edward Thomson committed -
Edward Thomson committed
-
Deprecation: export the deprecated functions properly
Edward Thomson committed -
Enable hard deprecation in our builds to ensure that we do not call deprecated functions internally.
Edward Thomson committed -
Add a CMake option to enable hard deprecation; the resultant library will _not_ include any deprecated functions. This may be useful for internal CI builds that create libraries that are not shared with end-users to ensure that we do not use deprecated bits internally.
Edward Thomson committed -
Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples.
Edward Thomson committed -
ci: skip ssh tests on macOS nightly
Edward Thomson committed -
Like 811c1c0f, disable the SSH tests on macOS until we can resolve the newly introduced infrastructure issues.
Edward Thomson committed -
CI build fixups
Edward Thomson committed -
SSH tests on macOS have begun failing for an unknown reason after an infrastructure upgrade to macOS 10.13.6. Disable those tests temporarily, until we can resolve it.
Edward Thomson committed
-
- 13 Feb, 2019 2 commits
-
-
Subtle changes in the host OS can have impacts in the CI system that may be hard to debug. We previously showed the results of `uname` which can be difficult to interpret. Provide more information where available.
Edward Thomson committed -
The URL was incorrect for the nightly badge image; it was erroneously showing the master branch continuous integration build badge.
Edward Thomson committed
-
- 12 Feb, 2019 1 commit
-
-
Include a build badge for `maint/v0.28` builds.
Edward Thomson committed
-
- 02 Feb, 2019 1 commit
-
-
v0.28 rc1
Edward Thomson committed
-
- 31 Jan, 2019 10 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Docs
Edward Thomson committed -
Edward Thomson committed
-
The mbedtls library uses a callback mechanism to allow downstream users to plug in their own receive and send functions. We implement `bio_read` and `bio_write` functions, which simply wrap the `git_stream_read` and `git_stream_write` functions, respectively. The problem arises due to the return value of the callback functions: mbedtls expects us to return an `int` containing the actual number of bytes that were read or written. But this is in fact completely misdesigned, as callers are allowed to pass in a buffer with length `SIZE_MAX`. We thus may be unable to represent the number of bytes written via the return value. Fix this by only ever reading or writing at most `INT_MAX` bytes.
Patrick Steinhardt committed -
The mbedtls stream implementation makes use of some global variables which are not marked as `static`, even though they're only used in this compilation unit. Fix this and remove a duplicate declaration.
Patrick Steinhardt committed -
Our `openssl_write` function calls `SSL_write` by passing in both `data` and `len` arguments directly. Thing is, our `len` parameter is of type `size_t` and theirs is of type `int`. We thus need to clamp our length to be at most `INT_MAX`.
Patrick Steinhardt committed -
Now that the function `git_stream__write_full` exists and callers of `git_stream_write` have been adjusted, we can lift logic for short writes out of the stream implementations. Instead, this is now handled either by `git_stream__write_full` or by callers of `git_stream_write` directly.
Patrick Steinhardt committed -
Similar to the write(3) function, implementations of `git_stream_write` do not guarantee that all bytes are written. Instead, they return the number of bytes that actually have been written, which may be smaller than the total number of bytes. Furthermore, due to an interface design issue, we cannot ever write more than `SSIZE_MAX` bytes at once, as otherwise we cannot represent the number of bytes written to the caller. Unfortunately, no caller of `git_stream_write` ever checks the return value, except to verify that no error occurred. Due to this, they are susceptible to the case where only partial data has been written. Fix this by introducing a new function `git_stream__write_full`. In contrast to `git_stream_write`, it will always return either success or failure, without returning the number of bytes written. Thus, it is able to write all `SIZE_MAX` bytes and loop around `git_stream_write` until all data has been written. Adjust all callers except the BIO callbacks in our mbedtls and OpenSSL streams, which already do the right thing and require the amount of bytes written.
Patrick Steinhardt committed -
The callback functions that implement the `git_stream` structure are only used inside of their respective implementation files, but they are not marked as `static`. Fix this.
Patrick Steinhardt committed
-
- 30 Jan, 2019 2 commits
-
-
Etienne Samson committed
-
Documentation fixes
Edward Thomson committed
-
- 28 Jan, 2019 4 commits
-
-
ci: add an individual coverity pipeline
Edward Thomson committed -
Edward Thomson committed
-
Coverity is back but it's only read-only! Agh. Just allow it to fail and not impact the overall job run.
Edward Thomson committed -
Etienne Samson committed
-