You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 14, 2021. It is now read-only.
Trying to reach remote repositories can (obviously) fail due to many different factors, but seeing an erroring stacktrace like below is not very helpful to the end-user:
In this particular case I happen to know why it fails (accessing private repo but missing key/bad git configuration), but it could be so many things.
Here's a case where I just pulled the plug:
$ git ls-remote --tags --quiet
fatal: unable to access 'https://github.com/jhauberg/gitdoctor.git/': Could not resolve host: github.com
Here's a case where remote no longer exists:
$ git ls-remote --tags --quiet
remote: Repository not found.
fatal: repository 'https://github.com/[redacted]/[redacted].git/' not found
I think, in most cases, the git command we're trying to execute will just exit with a fatal, unknown, error, like the error code 128 as seen in the above screenshot.
We absolutely should not try to determine the root cause, because that is going to get extremely out of scope as I see it. We should, however, not bail completely, as there is still potential to diagnose other defects (they don't all require remotes access).
I suppose we could point out during diagnosis that something did not work out and just move on, or even just skip it silently. It could also be noted lastly that some defects could not be diagnosed. I'm not sure what is most preferable.
Edit:
As it may be of use, the actual output/error for the above screenshot is:
$ git symbolic-ref --short refs/remotes/origin/HEAD
fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
Turns out that, though still related, is actually a separate issue entirely (see #3).
The text was updated successfully, but these errors were encountered:
So this issue can essentially be boiled down to whether or not we do check=True in subprocess.run, and, if we don't, how we make it clear, when, and if, something didn't go as expected before we move on.
jhauberg
changed the title
Unreachable remote repository
Dealing with unexpected errors
Feb 27, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bugSomething isn't workingdiscussionTopic is up for discussion
Trying to reach remote repositories can (obviously) fail due to many different factors, but seeing an erroring stacktrace like below is not very helpful to the end-user:
In this particular case I happen to know why it fails (accessing private repo but missing key/bad git configuration), but it could be so many things.
Here's a case where I just pulled the plug:
Here's a case where remote no longer exists:
I think, in most cases, the git command we're trying to execute will just exit with a fatal, unknown, error, like the error code 128 as seen in the above screenshot.
We absolutely should not try to determine the root cause, because that is going to get extremely out of scope as I see it. We should, however, not bail completely, as there is still potential to diagnose other defects (they don't all require remotes access).
I suppose we could point out during diagnosis that something did not work out and just move on, or even just skip it silently. It could also be noted lastly that some defects could not be diagnosed. I'm not sure what is most preferable.
Edit:
As it may be of use, the actual output/error for the above screenshot is:
Turns out that, though still related, is actually a separate issue entirely (see #3).
The text was updated successfully, but these errors were encountered: