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
A typical github.com SSH url is something like git@github.com:user/repo.git. If the user is a number, then it gets parsed as a port. The problem is that GitHub has users whose names are just numbers.
Parsing that number as a port makes sense in every context unless we know that it's a GitHub (or GitHub Enterprise) URL. GitHub doesn't allow SSH over any port except 22, and GitHub Enterprise doesn't either (it's not configurable by the admin). They probably do this specifically to avoid this issue; if the port can't be anything but 22, then the URL format is no longer ambiguous; that thing after a colon is always a user name.
Not sure what to do about this. For github.com you could probably add a bunch of logic to git-url-parse after you get it back from git-up and see that the domain is github.com... it would involve doing really heavy surgery on the object to fix it up, but it's technically possible. That doesn't solve the problem for Enterprise URLs though, and I don't see how that's solvable without being able to pass options to git-url-parse.
The text was updated successfully, but these errors were encountered:
Not sure what to do about this one...
A typical github.com SSH url is something like
git@github.com:user/repo.git
. If theuser
is a number, then it gets parsed as a port. The problem is that GitHub has users whose names are just numbers.Parsing that number as a port makes sense in every context unless we know that it's a GitHub (or GitHub Enterprise) URL. GitHub doesn't allow SSH over any port except 22, and GitHub Enterprise doesn't either (it's not configurable by the admin). They probably do this specifically to avoid this issue; if the port can't be anything but 22, then the URL format is no longer ambiguous; that thing after a colon is always a user name.
Not sure what to do about this. For
github.com
you could probably add a bunch of logic togit-url-parse
after you get it back fromgit-up
and see that the domain isgithub.com
... it would involve doing really heavy surgery on the object to fix it up, but it's technically possible. That doesn't solve the problem for Enterprise URLs though, and I don't see how that's solvable without being able to pass options togit-url-parse
.The text was updated successfully, but these errors were encountered: