[DRAFT] Improve SSH URL parsing and reporting #4975
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Git LFS supports both "bare" SSH URLs, of the form "user@host:path", and SSH URIs of the form "ssh://user@host/path", when parsing its configuration fields. However, we do not at present retain any record of this difference, and so we are not able to reconstruct the original input when reporting SSH endpoints in the "git lfs env" command. We also do not report a non-default SSH port, if one was configured, in the output from that command, leading to confusion when the input configuration was a URI like "ssh://example.com:1337/path" and we report it as "example.com:/path", which looks like we have dropped the port entirely. We therefore add a URIFormat member to our SSHMetadata structure and set this true only when parsing an SSH URI with a "ssh://" scheme. We also add a URLFromMetadata() helper function in our "ssh" package which the "git lfs env" command can now use to format SSH metadata to match its original input format, including any non-default port number. As well, we revise one change which was introduced in commit a0190a6 of PR git-lfs#4446, whereby the lfshttp.EndpointFromBareSshUrl() function always strips off the leading path separator. The code actually only performs this action if the path returned by EndpointFromSshUrl() begins with a slash character, but since that function expects an SSH URI and we construct one as its argument, it will always return an absolute path with a leading separator, and so we always strip that off. Instead, we now detect whether the configured path in the bare SSH URL is an absolute or relative one before we generate a temporary URI to pass to EndpointFromSshUrl(). We can then remove the leading slash always returned by that function if the original input had a relative path and not otherwise. We also expand an existing test in the t/t-env.sh file so as to confirm that our changes work as expected with a variety of bare SSH URLs.
The SSHMetadata structure contains a Port field, so let's check that consistently in our EndpointFinder tests, even when it's just an empty string.
chrisd8088
force-pushed
the
ssh-endpoint-env
branch
from
19cf622
to
6622d27
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work in Progress
TODO: improve parsing of bare [...:port] format
check on terminology
check on relative paths in bare format
Git LFS supports both "bare" SSH URLs, of the form
user@host:path, and SSH URIs of the formssh://user@host/path, when parsing its configuration fields. However, we do not at present retain any record of this difference, and so we are not able to reconstruct the original input when reporting SSH endpoints in thegit lfs envcommand.We also do not report a non-default SSH port, if one was configured, in the output from that command, leading to confusion when the input configuration was a URI like
ssh://example.com:1337/pathand we report it asexample.com:/path, which looks like we have dropped the port entirely.We therefore add a
URIFormatmember to ourSSHMetadatastructure and set this true only when parsing an SSH URI with assh://scheme. We also add aURLFromMetadata()helper function in oursshpackage which thegit lfs envcommand can now use to format SSH metadata to match its original input format, including any non-default port number.As well, we revise one change which was introduced in commit a0190a6 of PR #4446, whereby the
lfshttp.EndpointFromBareSshUrl()function always strips off the leading path separator. The code actually only performs this action if the path returned byEndpointFromSshUrl()begins with a slash character, but since that function expects an SSH URI and we construct one as its argument, it will always return an absolute path with a leading separator, and so we always strip that off.Instead, we now detect whether the configured path in the bare SSH URL is an absolute or relative one before we generate a temporary URI to pass to
EndpointFromSshUrl(). We can then remove the leading slash always returned by that function if the original input had a relative path and not otherwise.We also expand an existing test in the
t/t-env.shfile so as to confirm that our changes work as expected with a variety of bare SSH URLs.Intended to resolve #5184.