Page MenuHomePhabricator

Find the minimal git version to use for protocol v2
Closed, ResolvedPublic

Description

The git client had protocol v2 introduced in 2.18. It has then been further improved and 2.26 turns it on by default.

Debian has the following versions:

Jessie (EOL)2.1.4
Stretch2.11.0
Stretch backports2.20.1
Buster2.20.1
testing2.27.0

Jessie is EOL and we only have a few apps and CI containers still using it.

We should probably avoid Debian backports since they disappear before the distribution is EOL. Then it is straightforward to have a version kept in a component to prevent this.

The big question is what was still broken from 2.20 to 2.26. But maybe 2.20 is fine.

We have the list of versions in use on servers and images at https://debmonitor.wikimedia.org/packages/git

Event Timeline

From git changelog

2.18.0

  • A new version of the transport protocol is being worked on.

2.19.0

  • git clone / git fetch did not send ref prefixes

2.20.0

  • git fetch in shallow repository failed to fetch full history
  • git fetch was a bit loose parsing responses

2.21.0

  • git fetch-pack now can talk the version 2 protocol - (that is to receive missing objects)
  • "git fetch" and "git upload-pack" learned to send all exchanges over the sideband channel while talking the v2 protocol.
  • v2 upload-pack failed to honor hidden-ref configuration (transfer.hiderefs)
    • that is for the server side, gerrit uses jGit.
    • the zuul-merger uses git but does not have hide references

2.22.0

  • Protocol v2 support in "git fetch-pack" of shallow clones has been corrected.

2.26.0

  • Fix for a bug revealed by a recent change to make the protocol v2 the default.
  • The transport protocol version 2 becomes the default one.

Apparently to fix and edge case when doing a partial clone and fetch.

2.27.0

  • 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.
    • It often fetches much than what is needed. Got reported by people fetching from linux-next
  • protocol v2 had shorter negotiation rounds but significantly larger packfiles.
  • The server-end of the v2 protocol to serve "git clone" and "git fetch" was not prepared to see a delim packets at unexpected places, which led to a crash.
    • Gerrit uses jGit so not affected.

2.27.0

  • "feature.experimental" configuration variable is to let volunteers easily opt into a set of newer features, which use of the v2 transport protocol is now a part of.
  • On-the-wire protocol v2 easily falls into a deadlock between the remote-curl helper and the fetch-pack process when the server side prematurely throws an error and disconnects. The communication has been updated to make it more robust.
    • The example given is git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
hashar claimed this task.

I have already switched releng/ci-src-setup to Buster to get git 2.20 ( https://gerrit.wikimedia.org/r/c/integration/config/+/608013 ) and switched bunch of jobs to it https://gerrit.wikimedia.org/r/c/integration/config/+/608069

That seems to behave properly for those use cases.

So I guess 2.20 is good enough for us.

On a second inspection, we might want fetch-pack to support v2 which got released in 2.21 4316ff306812025385a71519f7f71abaa36b3c31

I am not quite sure whether it is a problem though. I am assuming fetch works just fine.