scalar: can we set `http.version=HTTP/1.1` for ADO scalar clones?

[derrickstolee]

We've noticed that macOS users of microsoft/git need to set http.version=HTTP/1.1 in their global config before their scalar clones can connect to ADO and the gvfs/config endpoint.

I know that we have some mechanisms to know if we are cloning against ADO and force the GVFS Protocol. Could we use similar logic to enable this config to get around the issues ADO is having with HTTP/2.0?

[dscho]

I guess configuring http.https://dev.azure.com.version=HTTP/1.1 should do the job?

[derrickstolee]

The thing I'd like to avoid is continuing to keep an extra step where a scalar clone doesn't work right away and the way it breaks it unhelpful. It just has an error like Waiting to retry after network error.

We have setup docs that tell users to set this config in advance, but users sometimes go by memory and forget that step.

[derrickstolee]

I guess configuring http.https://dev.azure.com.version=HTTP/1.1 should do the job?

Sometimes users use the https://<org>.visualstudio.com URL still.

[dscho]

@Copilot I am going to assign this ticket to you in a moment; In preparation for this, I want you to understand the following things:

1. The change will need to be in scalar.c
2. It will need to configure http.<url>.version as part of the initialization (find the function that already configures plenty of Git config settings).
3. This initialization should only take place if the remote.origin.url setting is referring to an Azure Repo, i.e. dev.azure.com or *.visualstudio.com.
4. Finally, there will need to be a new test case to verify that this works (find the t/*-scalar.sh file).
5. This test case should not be an integration test and actually clone anything from Azure DevOps! Instead, it needs to set a global config setting to redirect the https://dev.azure.com/* URL to the current directory, using the http.<url>.insteadOf key.
6. The test case should then simply initialize a Scalar clone (which, thanks to that insteadOf setting, clones the current directory instead), and then verify that the http.<url>.version setting is configured.
7. Instead of hints 5 and 6, there might be a much easier way to test this simply by setting remote.origin.url and running scalar reinit (I am not quite sure that the command is called reinit, you will have to see for yourself), and then verify the http.version setting.

Good luck!