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
[ANNOUNCE] Git v2.27.0-rc1
A release candidate Git v2.27.0-rc1 is now available for testing at the usual places. It is comprised of 491 non-merge commits since v2.26.0, contributed by 55 people, 16 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.27.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ash Holland, Christopher Warrington, Emma Brooks, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Abhishek Kumar, Alban Gruin, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine, Garima Singh, Hans Jerry Illikainen, Heba Waly, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Patrick Steinhardt, Philippe Blain, Phillip Wood, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, Thomas Gummerer, and Todd Zullinger. Git 2.27 Release Notes (draft) == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real changes. * The interactive input from various codepaths are consolidated and any prompt possibly issued earlier are fflush()ed before we read. * Allow "git rebase" to reapply all local commits, even if the may be already in the upstream,
