pip's CI failed during GitHub's unauthenticated git protocol brownout

In PR #10628 some of the CI runs failed with causes unrelated to the PR.

For example the test_download_vcs_link test failed with:

----------------------------- Captured stdout call -----------------------------
Script result: python -m pip download -d . git+git://github.com/pypa/pip-test-package.git
  return code: 1
-- stderr: --------------------
  Running command git clone --filter=blob:none -q git://github.com/pypa/pip-test-package.git /tmp/pytest-of-runner/pytest-1/popen-gw0/test_download_vcs_link0/workspace/tmp/pip-req-build-vtgbw0aj
  fatal: remote error:
    The unauthenticated git protocol on port 9418 is no longer supported.
  Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

(see https://github.com/pypa/pip/runs/4081019730?check_suite_focus=true#step:8:1905)

Checking https://github.blog/2021-09-01-improving-git-protocol-security-github/ I see that November 2nd (the day of the PR) was one of the scheduled brownout dates where their changes were temporarily being applied.

From their timeline, it seems there will be another brownout on 2022-01-11, followed by final disablement on 2022-03-15.

Pip’s tests will need to be updated by then, or CI will start failing.

[uranusjr]

I think we can safely declare git:// unsupported (by removing the tests, but not the actual functionality). The protocol was initially invented because cloning over HTTP was extremely inefficient back in the early days of Git, but no longer relevant now with smart HTTP support being widely available (it’s released for 5+ years at this point, I think). The implementation can stick around (it’s mostly done in the actual git implementation anyway, not in pip), but we don’t need to test it anymore and can rely on user reports if anything breaks IMO. We should add a note in documentation as well.

[ronnix]

We’ve had issues during the GitHub brownout yesterday with pip installs that were not using the unencrypted git protocol directly (they were using git+https:// which should be OK), where the failure was during the git submodule update --init --recursive -q that pip does after the repository clone. That operation somehow triggered the sameThe unauthenticated git protocol on port 9418 is no longer supported error message from GitHub, not sure why.