Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scalar/GVFS not working on latest MacOS (Sequoia) #671

Open
amrmesbah opened this issue Jul 10, 2024 · 7 comments
Open

Scalar/GVFS not working on latest MacOS (Sequoia) #671

amrmesbah opened this issue Jul 10, 2024 · 7 comments

Comments

@amrmesbah
Copy link

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
Copy link

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
Copy link
Member

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
Copy link
Member

dscho commented Jul 11, 2024

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Member

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.

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

No branches or pull requests

5 participants