-
Notifications
You must be signed in to change notification settings - Fork 91
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 clone: make 404s on gvfs/config
silent
#384
Comments
I bet that it is both from
The work-around is most likely to guard the message behind |
Hello, @derrickstolee, is this issue is still open I like to work on this issue. I am new to open source & want to contribute. |
Hi @yash112-lang. Yes, this issue is still open. Please start looking at those lines that @dscho links above. Let us know if you have trouble. Thanks! |
Hi @derrickstolee, is this issue still open? I see that #504 is open but don't think it is actively being worked on right now. |
Thanks, @denizariyan for the reminder. Is @abdurraheemali around to comment on whether they will continue with this work? @dscho supplied some recommended changes, but we're exited to see a contribution helping in this area. |
I totally forgot I had a PR open here. I'll probably continue with it today. |
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested.
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
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 #384 since those requests won't happen against non-ADO URLs unless requested. Signed-off-by: Derrick Stolee <stolee@gmail.com>
I ran
scalar clone
against a GitHub URL and saw these lines in the output:These are likely related to the
/gvfs/config
endpoint, which doesn't exist on GitHub (and many others). This error is likely being output from Curl, but we should pass the correct option to make this be silent.The text was updated successfully, but these errors were encountered: