Bugix release v0.27.7 #4846
Merged
Bugix release v0.27.7 #4846
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I've redone this PR. Instead of pulling in #4798, I decided to use the backports script to cherry-pick all relevant CI PRs. This is because #4798 was missing the XML clar changes, and backporting these was near impossible due to dozens of conflicts. With the backporting script it was a lot more manageable. @ethomson, please let me know if that's okay for you. I've also spotted some out-of-date backports in #4798, which have been fixed by the reroll. Diff to v1: |
|
I very intentionally didn't include the XML changes to clar. Changing the way our test runner works in a rather fundamental way like that seemed very risky for a point release, that's why I had done all this work manually. |
|
I thought it might be something like that, but to be honest I don't quite get the risk,. First, the new XML stuff is optional and only in place with "-r". Sure, it might be the new code actually broke something even without that switch. Second, it's only our tests and not some kind of API. But even if people have scripted against it e.g. in packaging instructions, it would still work just fine as the new XML mode is optional after all. And without the XML stuff, the CI is only half-functioning (well, at least not optimally functioning) as it cannot deduce any information about the tests. |
|
Sure - I don't think it's a big risk, but we changed the way we buffer (or don't) test results, even when you're not using the XML output. But at this point we've been using it on the master branch for a while now, so it's probably a reasonable enough risk. |
|
Fair enough. I'm fine with taking this risk. That being said, I'd also be fine with reverting to the old state of this PR using #4798 if you wish, especially as you're the one who has done most of the migration to VSTS. |
|
🤷♂️ |
|
I think we should probably just merge this. The important thing for me is getting the new CI scripts merged so that we can set up all the platforms on our point releases. 👍 |
We were previously conflating any error into GIT_ENOTFOUND, which might or might not be correct. This fixes the code so a config error is bubbled up, as well as preserving the semantics in the face of worktree-repositories
(cherry picked from commit f9e2802)
When we add entries to a treebuilder we validate them. But we validate even those that we're adding because they exist in the base tree. This disables using the normal mechanisms on these trees, even to fix them. Keep track of whether the entry we're appending comes from an existing tree and bypass the name and id validation if it's from existing data. (cherry picked from commit 2dff7e2)
(cherry picked from commit f00db9e)
String operations in libgit2 are supposed to never receive `NULL`, e.g. they are not `NULL`-save. In the case of `git__linenlen()`, invocation with `NULL` leads to undefined behavior. In a `git_parse_ctx` however, the `content` field used in these operations was initialized to `NULL` if the `git_parse_ctx_init()` was called with `NULL` for `content` or `0` for `content_len`. For the latter case, the initialization function even contained some logic for initializing `content` with `NULL`. This commit mitigates triggering undefined behavior by rewriting the logic. Now `content` is always initialized to a non-null buffer. Instead of a null buffer, an empty string is used for denoting an empty buffer. (cherry picked from commit d1bfe61)
(cherry picked from commit c4d7fa9)
(cherry picked from commit 019409b)
(cherry picked from commit ec76a1a)
(cherry picked from commit f140950)
(cherry picked from commit 6698e05)
The function `git_diff_find_similar` keeps a function of cache similarity metrics signatures, whose size depends on the number of deltas passed in via the `diff` parameter. In case where the diff is empty and thus doesn't have any deltas at all, we may end up allocating this cache via a call to `git__calloc(0, sizeof(void *))`. At least on AIX, allocating 0 bytes will result in a `NULL` pointer being returned, which causes us to erroneously return an OOM error. Fix this situation by simply returning early in case where we are being passed an empty diff, as we cannot find any similarities in that case anyway. (cherry picked from commit c65568d)
This performs a compile-check by using CMake support, to differentiate the GNU version from the BSD version of qsort_r. Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked against CMake 2.8.11. (cherry picked from commit 1a9cc18)
(cherry picked from commit 581d549)
The documentation states that git_worktree_unlock returns 0 on success, and 1 on success if the worktree wasn't locked. Turns out we were returning 0 in any of those cases. (cherry picked from commit 59c2e70)
At line 594, we do this : if (error < 0) return error; but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return uninitialized stack data. (cherry picked from commit aa8cb58)
Otherwise we'll return stack data to the caller. (cherry picked from commit 22d013b)
While most systems provide a separate iconv library against which
applications can link, musl based systems do not provide such a library.
Instead, iconv functions are directly included in the C library. As our
current CMake module to locate the iconv library only checks whether a
library exists somewhere in the typical library directories, we will
never build libgit2 with libiconv support on such systems.
Extend the iconv module to also search whether libc provides iconv
functions, which we do by checking whether the `iconv_open` function
exists inside of libc. If this is the case, we will default to use the
libc provided one instead of trying to use a separate libiconv. While
this changes which iconv we use on systems where both libc and an
external libiconv exist, to the best of my knowledge common systems only
provide either one or the other.
Note that libiconv support in musl is held kind of basic. To quote musl
libc's page on functional differences from glibc [1]:
The iconv implementation musl is very small and oriented towards
being unobtrusive to static link. Its character set/encoding
coverage is very strong for its size, but not comprehensive like
glibc’s.
As we assume iconv to be a lot more capable than what musl provides,
some of our tests will fail if using iconv on musl-based platforms.
[1]: https://wiki.musl-libc.org/functional-differences-from-glibc.html
(cherry picked from commit 2e2d8c6)
Previously we would assert in index_free because the reader incrementation would not be balanced. Release the snapshot normally, so the variable gets decremented before the index is freed. (cherry picked from commit c70713d)
(cherry picked from commit fa48d2e)
(cherry picked from commit e0afd1c)
When porting, we overlooked that the difference between git's and our's time representation and copied their way of getting the max value. Unfortunately git was using unsigned integers, so `~0ll` does correspond to their max value, whereas for us it corresponds to `-1`. This means that we always consider the last date to be smaller than the current commit's and always think commits are interesting. Change the initial value to the macro that gives us the maximum value on each platform so we can accurately consider commits interesting or not. (cherry picked from commit 46f3512)
…tamp This is not a big deal, but it does make us match git more closely by checking only the first. The lists are sorted already, so there should be no functional difference other than removing a possible check from every iteration in the loop. (cherry picked from commit 12a1790)
Blobs that have been marked as uninteresting should not be inserted into packbuilder when inserting a tree. The check as to whether a blob was uninteresting looked at the status for the tree itself instead of the blob. This could cause significantly larger packfiles. (cherry picked from commit b36cc7a)
We do not currently have any warnings in this regard, but it's good practice to have them on in case we introduce something. (cherry picked from commit f2c1153)
GCC warns by default when implicitly converting integers to pointers or the other way round, and commit fa48d2e (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. (cherry picked from commit dbb4a58)
While GCC enables int-conversion warnings by default, it will currently only warn about such errors even in case where "-DENABLE_WERROR=ON" has been passed to CMake. Explicitly enable int-conversion warnings by using our `ENABLE_WARNINGS` macro, which will automatically use "-Werror=int-conversions" in case it has been requested by the user. (cherry picked from commit aa0ae59)
Otherwise we return a NULL context, which will get dereferenced in apply_credentials. (cherry picked from commit 1c949ce)
auth_context_match returns 0 instead of -1 for unknown schemes to not fail in situations where some authentication schemes are supported and others are not. apply_credentials is adjusted to handle auth_context_match returning 0 without producing authentication context. (cherry picked from commit 475db39)
(cherry picked from commit bfec652)
Early Windows TLS 1.2 implementations have an issue during key exchange with OpenSSL implementations that cause negotiation to fail with the error "the buffer supplied to a function was too small." This is a transient error on the connection, so when that error is received, retry up to 5 times to create a connection to the remote server before actually giving up. (cherry picked from commit dc371e3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This cherry-picks all pull requests currently labelled "backport-0.27.6". Most notable is probably the change to our CI infrastructure. Please have a look and let me know if any commits should be dropped or if I missed some importants PRs that should be part of this.