Protocol v2 in v2.27 (Re: Re* [ANNOUNCE] Git v2.27.0-rc1)
(other lists -> bcc)
Junio C Hamano wrote:
> Jeff King 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
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)
+ 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);
Re: Re* [ANNOUNCE] Git v2.27.0-rc1
On Wed, May 20, 2020 at 01:31:30PM -0700, Junio C Hamano wrote: > 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) Hmm, yeah, that does make it feel funny. I'd argue that it probably would have been worth promoting a bit more in v2.26, but it is obviously too late now. > -- >8 -- > Subject: [PATCH] RelNotes: advertise the demotion of protocol v2 What you have here looks fine, but I'd be OK if we just left it as-is, too, given the v2.26 mention. -Peff
Re: [ANNOUNCE] Git v2.27.0-rc1
Hi folks, > Shourya Shukla (4): > submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb' > gitfaq: files in .gitignore are tracked > gitfaq: fetching and pulling a repository > submodule: port subcommand 'set-url' from shell to C Could you please review the minor fix in https://public-inbox.org/git/20200519045301.gy24...@pobox.com/ It helps the backward compatibility for packaging on CentOS6. Thanks, Son Luong.
Re* [ANNOUNCE] Git v2.27.0-rc1
Jeff King writes: > On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > >> Git 2.27 Release Notes (draft) >> == >> >> Updates since v2.26 >> --- >> >> Backward compatibility notes > > 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) -- >8 -- Subject: [PATCH] RelNotes: advertise the demotion of protocol v2 In the upcoming release, the transport protocol v2 is no longer the default; note it in the backward compatibility section. Suggested-by: Jeff King Signed-off-by: Junio C Hamano --- Documentation/RelNotes/2.27.0.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/RelNotes/2.27.0.txt b/Documentation/RelNotes/2.27.0.txt index 5fb8c0cf67..95a8d338ad 100644 --- a/Documentation/RelNotes/2.27.0.txt +++ b/Documentation/RelNotes/2.27.0.txt @@ -24,6 +24,10 @@ Backward compatibility notes users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. + * The transport protocol version 2, which was promoted to the default + in Git 2.26 release, turned out to have some remaining rough edges, + so it has been demoted from the default. + UI, Workflows & Features
Re: [ANNOUNCE] Git v2.27.0-rc1
Jeff King writes: > On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > >> Git 2.27 Release Notes (draft) >> == >> >> Updates since v2.26 >> --- >> >> Backward compatibility notes > > Is it worth mentioning here the reversion of v2 as the default protocol? Yeah, that is a good suggestion. The fix inside v2 is not worth reporting, but the change of the default is noteworthy enough to be at the top.
Re: [ANNOUNCE] Git v2.27.0-rc1
On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > Git 2.27 Release Notes (draft) > == > > Updates since v2.26 > --- > > Backward compatibility notes 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. -Peff
