summaryrefslogtreecommitdiff
path: root/protocol.c
AgeCommit message (Collapse)AuthorFilesLines
2020-09-25protocol: re-enable v2 protocol by defaultLibravatar Jeff King1-5/+1
Protocol v2 became the default in v2.26.0 via 684ceae32d (fetch: default to protocol version 2, 2019-12-23). More widespread use turned up a regression in negotiation. That was fixed in v2.27.0 via 4fa3f00abb (fetch-pack: in protocol v2, in_vain only after ACK, 2020-04-27), but we also reverted the default to v0 as a precuation in 11c7f2a30b (Revert "fetch: default to protocol version 2", 2020-04-22). In v2.28.0, we re-enabled it for experimental users with 3697caf4b9 (config: let feature.experimental imply protocol.version=2, 2020-05-20) and haven't heard any complaints. v2.28 has only been out for 2 months, but I'd generally expect people turning on feature.experimental to also stay pretty up-to-date. So we're not likely to collect much more data by waiting. In addition, we have no further reports from people running v2.26.0, and of course some people have been setting protocol.version manually for ages. Let's move forward with v2 as the default again. It's possible there are still lurking bugs, but we won't know until it gets more widespread use. And we can find and squash them just like any other bug at this point. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-14config: fix leaks from git_config_get_string_const()Libravatar Jeff King1-1/+1
There are two functions to get a single config string: - git_config_get_string() - git_config_get_string_const() One might naively think that the first one allocates a new string and the second one just points us to the internal configset storage. But in fact they both allocate a new copy; the second one exists only to avoid having to cast when using it with a const global which we never intend to free. The documentation for the function explains that clearly, but it seems I'm not alone in being surprised by this. Of 17 calls to the function, 13 of them leak the resulting value. We could obviously fix these by adding the appropriate free(). But it would be simpler still if we actually had a non-allocating way to get the string. There's git_config_get_value() but that doesn't quite do what we want. If the config key is present but is a boolean with no value (e.g., "[foo]bar" in the file), then we'll get NULL (whereas the string versions will print an error and die). So let's introduce a new variant, git_config_get_string_tmp(), that behaves as these callers expect. We need a new name because we have new semantics but the same function signature (so even if we converted the four remaining callers, topics in flight might be surprised). The "tmp" is because this value should only be held onto for a short time. In practice it's rare for us to clear and refresh the configset, invalidating the pointer, but hopefully the "tmp" makes callers think about the lifetime. In each of the converted cases here the value only needs to last within the local function or its immediate caller. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21config: let feature.experimental imply protocol.version=2Libravatar Jonathan Nieder1-0/+4
Git 2.26 used protocol v2 as its default protocol, but soon after release, users noticed that the protocol v2 negotiation code was prone to fail when fetching from some remotes that are far ahead of others (such as linux-next.git versus Linus's linux.git). That has been fixed by 0b07eecf6ed (Merge branch 'jt/v2-fetch-nego-fix', 2020-05-01), but to be cautious, we are using protocol v0 as the default in 2.27 to buy some time for any other unanticipated issues to surface. To that end, let's ensure that users requesting the bleeding edge using the feature.experimental flag *do* get protocol v2. This way, we can gain experience with a wider audience for the new protocol version and be more confident when it is time to enable it by default for all users in some future Git version. Implementation note: this isn't with the rest of the feature.experimental options in repo-settings.c because those are tied to a repository object, whereas this code path is used for operations like "git ls-remote" that do not require a repository. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-22Revert "fetch: default to protocol version 2"Libravatar Jonathan Nieder1-1/+1
This reverts commit 684ceae32dae726c6a5c693b257b156926aba8b7. Users fetching from linux-next and other kernel remotes are reporting that the limited ref advertisement causes negotiation to reach MAX_IN_VAIN, resulting in too-large fetches. Reported-by: Lubomir Rintel <lkundrak@v3.sk> Reported-by: "Dixit, Ashutosh" <ashutosh.dixit@intel.com> Reported-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15fetch: default to protocol version 2Libravatar Jonathan Nieder1-1/+1
The Git users at $DAYJOB have been using protocol v2 as a default for ~1.5 years now and others have been also reporting good experiences with it, so it seems like a good time to bump the default version. It produces a significant performance improvement when fetching from repositories with many refs, such as https://chromium.googlesource.com/chromium/src. This only affects the client, not the server. (The server already defaults to supporting protocol v2.) The protocol change is backward compatible, so this should produce no significant effect when contacting servers that only speak protocol v0. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15protocol test: let protocol.version override GIT_TEST_PROTOCOL_VERSIONLibravatar Jonathan Nieder1-6/+5
The GIT_TEST_PROTOCOL_VERSION environment variable can be used to upgrade the version of Git protocol used in tests. If both GIT_TEST_PROTOCOL_VERSION and 'protocol.version' are set, the higher value wins. For usage within tests, these semantics are too complex. Instead, always use the value from protocol.version configuration when it is set, falling back to GIT_TEST_PROTOCOL_VERSION. This way, the envvar provides a reliable preview of what will happen if the default protocol version is changed. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07tests: define GIT_TEST_PROTOCOL_VERSIONLibravatar Jonathan Tan1-2/+15
Define a GIT_TEST_PROTOCOL_VERSION environment variable meant to be used from tests. When set, this ensures protocol.version is at least the given value, allowing the entire test suite to be run as if this configuration is in place for all repositories. As of this patch, all tests pass whether GIT_TEST_PROTOCOL_VERSION is unset or set to 0. Some tests fail when GIT_TEST_PROTOCOL_VERSION is set to 1 or 2, but this will be dealt with in subsequent patches. This is based on work by Ævar Arnfjörð Bjarmason. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14protocol: introduce enum protocol_version value protocol_v2Libravatar Brandon Williams1-0/+2
Introduce protocol_v2, a new value for 'enum protocol_version'. Subsequent patches will fill in the implementation of protocol_v2. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-17protocol: introduce protocol extension mechanismsLibravatar Brandon Williams1-0/+79
Create protocol.{c,h} and provide functions which future servers and clients can use to determine which protocol to use or is being used. Also introduce the 'GIT_PROTOCOL' environment variable which will be used to communicate a colon separated list of keys with optional values to a server. Unknown keys and values must be tolerated. This mechanism is used to communicate which version of the wire protocol a client would like to use with a server. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>