linux-kernel - Protocol v2 in v2.27 (Re: Re* [ANNOUNCE] Git v2.27.0-rc1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 20 May 2020 15:00:23 -0700
From:   Jonathan Nieder <jrnieder@...il.com>
To:     Junio C Hamano <gitster@...ox.com>
Cc:     Jeff King <peff@...f.net>, git@...r.kernel.org,
        Derrick Stolee <dstolee@...rosoft.com>
Subject: Protocol v2 in v2.27 (Re: Re* [ANNOUNCE] Git v2.27.0-rc1)

(other lists -> bcc)
Junio C Hamano wrote:
> Jeff King <peff@...f.net> writes:

>> Is it worth mentioning here the reversion of v2 as the default protocol?
>>
>> It does end up (along with the actual code fix) in the "fixes from
>> v2.26" section:
>>
>>>  * Those fetching over protocol v2 from linux-next and other kernel
>>>    repositories are reporting that v2 often fetches way too much than
>>>    needed.
>>>    (merge 11c7f2a30b jn/demote-proto2-from-default later to maint).
>>>
>>>  * The upload-pack protocol v2 gave up too early before finding a
>>>    common ancestor, resulting in a wasteful fetch from a fork of a
>>>    project.  This has been corrected to match the behaviour of v0
>>>    protocol.
>>>    (merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).
>>
>> but that's somewhat buried. I dunno. It is not likely to introduce _new_
>> compatibility issues, but perhaps folks looking into compatibility stuff
>> may want to know about the revert.
>
> The promotion in Git 2.26 was buried in the "performance &
> implementation details" section and not in the backward
> compatibility section, so it feels a bit funny to highlight the
> reversion.  In any case, here is what I prepared (but not committed
> yet)

Speaking of which, should we enable protocol v2 by default for people
with feature.experimental enabled, like this?

(This isn't part of the rest of the feature.experimental handling
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@...il.com>

diff --git c/Documentation/config/protocol.txt i/Documentation/config/protocol.txt
index 0b40141613e..c46e9b3d00a 100644
--- c/Documentation/config/protocol.txt
+++ i/Documentation/config/protocol.txt
@@ -48,7 +48,8 @@ protocol.version::
 	If set, clients will attempt to communicate with a server
 	using the specified protocol version.  If the server does
 	not support it, communication falls back to version 0.
-	If unset, the default is `0`.
+	If unset, the default is `0`, unless `feature.experimental`
+	is enabled, in which case the default is `2`.
 	Supported versions:
 +
 --
diff --git c/protocol.c i/protocol.c
index d390391ebac..d1dd3424bba 100644
--- c/protocol.c
+++ i/protocol.c
@@ -17,6 +17,7 @@ static enum protocol_version parse_protocol_version(const char *value)
 enum protocol_version get_protocol_version_config(void)
 {
 	const char *value;
+	int val;
 	const char *git_test_k = "GIT_TEST_PROTOCOL_VERSION";
 	const char *git_test_v;
 
@@ -30,6 +31,9 @@ enum protocol_version get_protocol_version_config(void)
 		return version;
 	}
 
+	if (!git_config_get_bool("feature.experimental", &val) && val)
+		return protocol_v2;
+
 	git_test_v = getenv(git_test_k);
 	if (git_test_v && *git_test_v) {
 		enum protocol_version env = parse_protocol_version(git_test_v);