Update ready-for-upstream
#1936
Merged
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
… NULL In preparation for applying the latest iteration of bw/config-h that was submitted to the Git mailing list, let's revert the original iteration. Signed-off-by: Johannes Schindelin <[email protected]>
…s NULL config: report a bug if git_dir exists without commondir This did happen at some stage, and was fixed relatively quickly. Make sure that we detect very quickly, too, should that happen again. Signed-off-by: Johannes Schindelin <[email protected]>
Revert this in preparation for applying the latest iteration of the patch. Signed-off-by: Johannes Schindelin <[email protected]>
Revert this in preparation for applying the latest iteration of the patch. Signed-off-by: Johannes Schindelin <[email protected]>
Revert this in preparation for applying the latest iteration of the patch. Signed-off-by: Johannes Schindelin <[email protected]>
http: add support for selecting SSL backends at runtime
As of version 7.56.0, curl supports being compiled with multiple SSL
backends.
This patch adds the Git side of that feature: by setting http.sslBackend
to "openssl" or "schannel", Git for Windows can now choose the SSL
backend at runtime.
This comes in handy on Windows because Secure Channel ("schannel") is
the native solution, accessing the Windows Credential Store, thereby
allowing for enterprise-wide management of certificates. For historical
reasons, Git for Windows needs to support OpenSSL still, as it has
previously been the only supported SSL backend in Git for Windows for
almost a decade.
The patch has been carried in Git for Windows for over a year, and is
considered mature.
Signed-off-by: Johannes Schindelin <[email protected]>
http: add support for disabling SSL revocation checks in cURL This adds support for a new http.schannelCheckRevoke config value. This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server. This config value should only be set to "false" if you are in an environment where revocation checks are blocked by the network, with no alternative options. This is only supported in cURL 7.44 or later. Note: originally, we wanted to call the config setting `http.schannel.checkRevoke`. This, however, does not work: the `http.*` config settings can be limited to specific URLs via `http.<url>.*` (and this feature would mistake `schannel` for a URL). Helped by Agustín Martín Barbero. Signed-off-by: Brendan Forster <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
http: when using Secure Channel, ignore sslCAInfo by default As of cURL v7.60.0, the Secure Channel backend can use the certificate bundle provided via `http.sslCAInfo`, but that would override the Windows Certificate Store. Since this is not desirable by default, let's tell Git to not ask cURL to use that bundle by default when the `schannel` backend was configured via `http.sslBackend`, unless `http.schannelUseSSLCAInfo` overrides this behavior. Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the patch that actually made it to the Git mailing list, let's revert this. Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the patch that actually made it to the Git mailing list, let's revert this. Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the patch that actually made it to the Git mailing list, let's revert this. Signed-off-by: Johannes Schindelin <[email protected]>
win32: replace pthread_cond_*() with much simpler code The Win32 CONDITION_VARIABLE has better performance and is easier to maintain, as the code is a lot shorter now (the semantics of the CONDITION_VARIABLE matches the pthread_cond_t very well). Note: CONDITION_VARIABLE is not available in Windows XP and below, but the declared minimal Windows version required to build and run Git for Windows is Windows Vista (which is also beyond its end-of-life, but for less long than Windows XP), so that's okay. Signed-off-by: Loo Rong Jie <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the latest iteration that was submitted to the Git mailing list, let's revert this here patch. Signed-off-by: Johannes Schindelin <[email protected]>
…d Git In preparation for applying the latest iteration that was submitted to the Git mailing list, let's revert this here patch. Signed-off-by: Johannes Schindelin <[email protected]>
…D is set In preparation for applying the latest iteration that was submitted to the Git mailing list, let's revert this here patch. Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the latest iteration that was submitted to the Git mailing list, let's revert this here patch. Signed-off-by: Johannes Schindelin <[email protected]>
In preparation for applying the latest iteration that was submitted to the Git mailing list, let's revert this here patch. Signed-off-by: Johannes Schindelin <[email protected]>
tests: fix GIT_TEST_INSTALLED's PATH to include t/helper/ We really need to be able to find the test helpers... Really. This change was forgotten when we moved the test helpers into t/helper/ Signed-off-by: Johannes Schindelin <[email protected]>
tests: respect GIT_TEST_INSTALLED when initializing repositories It really makes very, very little sense to use a different git executable than the one the caller indicated via setting the environment variable GIT_TEST_INSTALLED. Signed-off-by: Johannes Schindelin <[email protected]>
…ED is set t/lib-gettext: test installed git-sh-i18n if GIT_TEST_INSTALLED is set It makes very, very little sense to test the built git-sh-i18n when the user asked specifically to test another one. Signed-off-by: Johannes Schindelin <[email protected]>
…ed Git tests: do not require Git to be built when testing an installed Git We really only need the test helpers to be built in the worktree in that case, but that is not what we test for. On the other hand it is a perfect opportunity to verify that `GIT_TEST_INSTALLED` points to a working Git. So let's test the appropriate Git executable. While at it, also adjust the error message in the `GIT_TEST_INSTALLED` case. This patch is best viewed with `-w --patience`. Helped-by: Jeff King <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
tests: explicitly use `git.exe` on Windows On Windows, when we refer to `/an/absolute/path/to/git`, it magically resolves `git.exe` at that location. Except if something of the name `git` exists next to that `git.exe`. So if we call `$BUILD_DIR/git`, it will find `$BUILD_DIR/git.exe` *only* if there is not, say, a directory called `$BUILD_DIR/git`. Such a directory, however, exists in Git for Windows when building with Visual Studio (our Visual Studio project generator defaults to putting the build files into a directory whose name is the base name of the corresponding `.exe`). In the bin-wrappers/* scripts, we already take pains to use `git.exe` rather than `git`, as this could pick up the wrong thing on Windows (i.e. if there exists a `git` file or directory in the build directory). Now we do the same in the tests' start-up code. This also helps when testing an installed Git, as there might be even more likely some stray file or directory in the way. Note: the only way we can record whether the `.exe` suffix is by writing it to the `GIT-BUILD-OPTIONS` file and sourcing it at the beginning of `t/test-lib.sh`. This is not a requirement introduced by this patch, but we move the call to be able to use the `$X` variable that holds the file extension, if any. Note also: the many, many calls to `git this` and `git that` are unaffected, as the regular PATH search will find the `.exe` files on Windows (and not be confused by a directory of the name `git` that is in one of the directories listed in the `PATH` variable), while `/path/to/git` would not, per se, know that it is looking for an executable and happily prefer such a directory. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/git
that referenced
this pull request
Nov 19, 2018
This closes git-for-windows#1936 Signed-off-by: Johannes Schindelin <[email protected]>
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.
Quite a few of the branches in the sub-thicket called
ready-for-upstreamhave been contributed to the Git mailing list. Some of those did not survive contact with the Git mailing list without having to change.Let's update them.
(Except for the
create-empty-bundleone, which we addressed in this PR already.