Skip to content

Conversation

@bk2204
Copy link
Member

@bk2204 bk2204 commented Apr 26, 2023

Some time back, Git added support for protocol version 2 over HTTP. This is announced by the Git-Protocol header, the value of which Git expects to see as the GIT_PROTOCOL environment variable. If it receives that value, then it switches into protocol v2 mode.

While this is a nice to have in general, it's presently important to fix our testsuite in CI when testing in SHA-256 mode. In that mode, we set GIT_DEFAULT_HASH=sha256 to specify the default hash algorithm. In protocols v0 and v1, Git does not send a capabilities line by default (although one is accepted) in an empty repository, and if no such line is present, it's not possible to discern the hash algorithm in use.

Git recently (after 2.40) added a patch that resulted in empty repositories that are cloned not honouring GIT_DEFAULT_HASH in such a case, so if no refs are set, we end up with a SHA-1 repository, which makes our tests fail since they don't interoperate. This will likely be fixed upstream by both announcing a dummy capabilities line like for pushes and by restoring the use of GIT_DEFAULT_HASH when no hash algorithm can be explicitly determined.

In any event, none of this matters with protocol v2, since in that case capabilities are sent as part of the initial refs request and we always know the hash algorithm. Since this will always work for affected Git versions, let's make sure we enable protocol v2 in the test server if the client supports it.

Fixes #5352

Some time back, Git added support for protocol version 2 over HTTP.
This is announced by the `Git-Protocol` header, the value of which Git
expects to see as the `GIT_PROTOCOL` environment variable.  If it
receives that value, then it switches into protocol v2 mode.

While this is a nice to have in general, it's presently important to fix
our testsuite in CI when testing in SHA-256 mode.  In that mode, we set
`GIT_DEFAULT_HASH=sha256` to specify the default hash algorithm.  In
protocols v0 and v1, Git does not send a capabilities line by default
(although one is accepted) in an empty repository, and if no such line
is present, it's not possible to discern the hash algorithm in use.

Git recently (after 2.40) added a patch that resulted in empty
repositories that are cloned not honouring `GIT_DEFAULT_HASH` in such a
case, so if no refs are set, we end up with a SHA-1 repository, which
makes our tests fail since they don't interoperate.  This will likely be
fixed upstream by both announcing a dummy capabilities line like for
pushes and by restoring the use of `GIT_DEFAULT_HASH` when no hash
algorithm can be explicitly determined.

In any event, none of this matters with protocol v2, since in that case
capabilities are sent as part of the initial refs request and we always
know the hash algorithm.  Since this will always work for affected Git
versions, let's make sure we enable protocol v2 in the test server if
the client supports it.
@bk2204 bk2204 marked this pull request as ready for review April 26, 2023 20:49
@bk2204 bk2204 requested a review from a team as a code owner April 26, 2023 20:49
@bk2204 bk2204 merged commit e817124 into git-lfs:main Apr 26, 2023
@bk2204 bk2204 deleted the ci-fix-latest-git branch April 26, 2023 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix latest build CI to work with newer Git

2 participants