Scalar/GVFS not working on latest MacOS (Sequoia)

[amrmesbah]

Scalar clone doesn't work on MacOS Sequoia

Cloning https://dev.azure.com/office/office/_git/Office to /Volumes/Source/Office
This may take several minutes. A completed message will be printed when we are done.
Creating scalar cache at /Volumes/Source/.scalarCache
Initialized empty Git repository in /Volumes/Source/Office/src/.git/
Fatal (bug): Command failed: 'Command:/usr/local/bin/scalar clone https://dev.azure.com/office/office/_git/Office /Volumes/Source/Office --branch lkg/main/dev --local-cache-path /Volumes/Source/.scalarCache
Error:error: config: (curl:56) Failure when receiving data from the peer [transient]
fatal: failed to contact server via GVFS Protocol
'

[eschwieb]

this blocks Apple developers from setting up new Office enlistments on Macs running the Sequoia beta. Please fix this as soon as possible, as we are working on Office support for Xcode 16 and Sequoia and need to create new enlistments there.

[mjcheetham]

Error:error: config: (curl:56) Failure when receiving data from the peer [transient]

Have you tried running scalar clone with HTTP/1.1? I've seen some issues like this with HTTP/2 against Azure DevOps before:

scalar -c http.version "HTTP/1.1" clone https://dev.azure.com/office/office/_git/Office /Volumes/Source/Office --branch lkg/main/dev --local-cache-path /Volumes/Source/.scalarCache

[dscho]

If this problem persists, it might be a good idea to re-run the command after setting the environment variable GIT_TRACE_CURL to a local path and then analyzing the log that was written there.

[eschwieb]

ok, adding the '-c http.version="HTTP/1.1"' seems to do the trick. Scalar is indeed fetching data for me now. We will have to add that to our tooling that invokes scalar, as we don't do it manually. @amrmesbah FYI.

[amrmesbah]

Thank you, @mjcheetham is using HTTP/1.1 a good long term solution, in other words should we change our toolings to pass in '-c http.version="HTTP/1.1"' to scalar all the time or there are other implications on doing that?

[derrickstolee]

Thank you, @mjcheetham is using HTTP/1.1 a good long term solution, in other words should we change our toolings to pass in '-c http.version="HTTP/1.1"' to scalar all the time or there are other implications on doing that?

You can also run git config --global http.version HTTP/1.1 (or drop --global if isolated to a specific repo).

[mjcheetham]

or there are other implications on doing that?

As @derrickstolee said, setting this via git config is the best way to achieve this more permanently (per user --global, or per repo --local).

Unless Azure DevOps drops HTTP/1.1 support (unlikely) then I don't think there's going to be an issue.