scalar: make GVFS Protocol a forced choice #648
Conversation
|
This is a draft because I'm not sure how to feel about the change of behavior. My commit message is lacking, as well. I was trying very hard to get this issue diagnosed and fixed before the 2.45.0 release, but I didn't have the necessary information until it reproduced in machines my team owns. |
In the Office monorepo, we've recently had an uptick in issues with `scalar clone`. These issues didn't make sense at first and seemed like the users weren't using `microsoft/git` but instead the upstream version's `scalar clone`. Instead of using GVFS cache servers, they were attempting to use the Git protocol's partial clone (which times out). It turns out that what's actually happening is that some network issue is causing the connection with Azure DevOps to error out during the `/gvfs/config` request. In the Git traces, we see the following error during this request: (curl:56) Failure when receiving data from the peer [transient] This isn't 100% of the time, but has increased enough to cause problems for a variety of users. The solution being proposed in this pull request is to remove the fall-back mechanism and instead have an explicit choice to use the GVFS protocol. To avoid significant disruption to Azure DevOps customers (the vast majority of `microsoft/git` users who use `scalar clone` based on my understanding), I added some inferring of a default value from the clone URL. This fallback mechanism was first implemented in the C# version of Scalar in microsoft/scalar#339. This was an attempt to make the Scalar client interesting to non-Azure DevOps customers, especially as GitHub was about to launch the availability of partial clones. Now that the `scalar` client is available upstream, users don't need the GVFS-enabled version to get these benefits. In addition, this will resolve git#384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <[email protected]>
derrickstolee
force-pushed
the
scalar-no-gvfs
branch
from
af94e1f to
ae65fc6
Compare
|
While pairing with one of my engineers, we were able to isolate the reason different machines were having issue with the This change is now less of an emergency, because the recent increase in failures is understood. It would still be good to merge this because:
|
In the Office monorepo, we've recently had an uptick in issues with
scalar clone. These issues didn't make sense at first and seemed like the users weren't usingmicrosoft/gitbut instead the upstream version'sscalar clone. Instead of using GVFS cache servers, they were attempting to use the Git protocol's partial clone (which times out).It turns out that what's actually happening is that some network issue is causing the connection with Azure DevOps to error out during the
/gvfs/configrequest. In the Git traces, we see the following error during this request:This isn't 100% of the time, but has increased enough to cause problems for a variety of users.
The solution being proposed in this pull request is to remove the fall-back mechanism and instead have an explicit choice to use the GVFS protocol. To avoid significant disruption to Azure DevOps customers (the vast majority of
microsoft/gitusers who usescalar clonebased on my understanding), I added some inferring of a default value from the clone URL.This fallback mechanism was first implemented in the C# version of Scalar in microsoft/scalar#339. This was an attempt to make the Scalar client interesting to non-Azure DevOps customers, especially as GitHub was about to launch the availability of partial clones. Now that the
scalarclient is available upstream, users don't need the GVFS-enabled version to get these benefits.In addition, this will resolve #384 since those requests won't happen against non-ADO URLs unless requested.