Advanced HTTP transport configuration #627
Merged
Conversation
This file contains 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
Technically they can be any value (except for newlines and unescaped double quotes), and these values might be paths and everything that comes with it, like illformed UTF8. In order to be able to represent everything that git can represent, we don't enforce UTF8 anymore for subsection names. Note that section names and key names are required to be valid UTF8 (and even alphanumeric ascii), which makes illformed UTF8 very unlikely there.
….origin.url"`, add `section_by_key("remote.origin")` as well.
That way it's the most comfortable way to query values and very
similar to how git does it, too.
Additionally, sections can be obtained by section key, both mutably and immutably for completeness.
…named after URLs. `reference::remote::Name` was moved to `remote::Name` to represent all remote names without necessarily having been validated. Note that we also don't validate names anymore if read from configuration, but use it as is. This means that remotes can be read and written back even with invalid names.
We should one day turn that back but then again, `gix` isn't outputting vast amounts of data to stdout, and shouldn't, as in most modes it's actually collected to memory first. Hence optimal write performance to stdout/stderr shouldn't be our priority here.
Use `config.boolean(…)` instead.
This comes with changes to the `HTTP` trait which now requires a base-url to be provided as well.
…errides. That way environment variables represented via git-configuration can be integrated into git configuration, making clearer what's going to happen even when looking at the configuration via `gix config`. The implementation has to be careful though about assureing there is no more specific configuration key, like `http.<URL>.proxy` that would override the one from the environment, which always has the final word.
Byron
force-pushed
the
http-config
branch
2 times, most recently
from
8642fdc
to
907b5aa
Compare
…able with a comment. This is useful for providing more information about a value at hand, especially if it was added programmatically and then shows up in the configuration.
Byron
force-pushed
the
http-config
branch
4 times, most recently
from
4a7eb40
to
5edd637
Compare
That way it's possible to more easily interact with it later, for instance when one wants to delete it.
…:Options::cli_overrides()`.
…ethods usage in `&mut self`. That way it's easier to configure both the `full` and the `partial` trust instances of discovery options.
This means different things depending on the backend, and for `curl` it means a lot of debug-output on stderr.
Byron
force-pushed
the
http-config
branch
2 times, most recently
from
1e14b41
to
446b770
Compare
…hosts. This is a curl-first option which can reasonably be implemented for other backends as well and thus retains its curl-ish roots in full.
That way it's possible to deny using environment variables that affect the HTTP transport, like setting the proxy.
Using git-configuration to store overrides from the environment is helpful as it more tighly integrates with the best configuration system there is, and also is nicely visualizable. It's now done for transport related configuration as well as all other environment variables we previously queried on the fly.
… git-configuration flags. Now it's possible to map the environment variables `GIT_REPLACE_REF_BASE` and `GIT_NO_REPLACE_OBJECTS` to custom git configuration keys which can also be set, namely `gitoxide.odb.replaceObjectsRefBase` and `gitoxide.odb.noReplaceObjects`. Along with the possibility of disabling the usage of `GIT_` prefixed environment variables one reaches the previous level of control without making object replacement a special case.
… configuration. That way it becomes more obvious where values are coming from.
…_MEMORY` in git-configuration. That way there is a unified system for how to set values, which may be overridable by configuration variables or not. With this changes, the explicit application of environment variables for setting the cache isn't required anymore as everything happens using git-configuration, and automatically, while providing full control like before.
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.
Tasks
nameof the remote)curlwith all options available inhttp::Optionsprobably via git-config. Be aware of lower-case versions of these vars (for historical reasons) - set config overrides with special
Sourceto set priorities later.http_proxyas fallbackGIT_HTTP_PROXY_AUTHMETHODas overridesgitoxide.https.proxyFor later
http.<url>.*based option overridesis-terminalinstead ofatty