Merged
Conversation
aa9073c to
7097e2c
Compare
Currently, we only support local remotes using file URLs, but not local paths. This is a highly requested feature, however, so implement support for local paths as remotes. First, fix the handling of local paths we already have: the handling of absolute Unix-style paths. Instead of checking for the remote to contain a file URL to determine whether to append "info/lfs" to the URL, look to see if the URL we're using is a file URL, which will catch local paths which will have been rewritten as such by this point. The "info/lfs" part of the URL is not handled by the transfer adapter, so we don't want to add it on. If we get something that looks like it's not a URL, check if it's a file on the file system, and if so, don't attempt to interpret it as an SSH URL. This fixes the confusion with Windows paths, which resemble SSH-style locations with a single-letter alias as the host name. Finally, when turning a local path into a file URL, turn the path into an absolute one if possible and rewrite it using slashes, which is required for file URLs. Add several tests for the various cases: one for Unix-style paths, one for native paths, and one for relative paths.
chrisd8088
approved these changes
Nov 15, 2019
Member
There was a problem hiding this comment.
Nice work! Thank you for tackling this oft-requested feature!
While it's a bit unfortunate that the logic in NewEndpoint() has to cover so many cases (literally, case blocks) as well as variations within those, I don't see any alternatives, given the range of possible inputs. Since this clearly improves the handling of relative local paths, it all looks good ... thank you!
Member
Author
|
Yeah, I'd hope that we could have a more generic approach in the future, but for now, it's kind of a bear. The code is necessarily complicated by the fact that some Windows paths looks like SSH remotes; that's been the inconvenient issue preventing us from making progress on this before. |
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Oct 16, 2023
Our Server Discovery documentation describes how we form Git LFS server API endpoint URLs based on Git remotes and other Git and Git LFS configurations. This documentation was introduced in commit 21e1695 of PR git-lfs#1641 and has only been lightly modified since then. As discusssed in issue git-lfs#5528, we append "/info/lfs" to Git remote URLs, but only after rewriting those URLs according to any "url.{name}.insteadOf" configurations, which is somewhat counter to what is implied by Git's own documentation of these settings. We may change this behaviour in a future Git LFS major release. For the present, though, we simply add a fuller description of how we convert Git remote URLs into Git LFS API server URLs to our documentation, specifically touching on the sequence in which we rewrite, convert, and append the "/info/lfs" path segments to the remote URLs. In PR git-lfs#3748 we added support for Git LFS endpoints defined by "file://" URLs, and in PR git-lfs#3918 we enhanced this by also accepting local file paths in remote URLs, so we also include comments on how we handle these cases in our new documentation. Further, although support for distinct URLs used only for upload operations has existed since PR git-lfs#949, it is not mentioned in our Server Discovery documentation, so we add notes on this feature now as well. 4469 - default remotes (lfsdefault, lfspushdefault) 5066 - autodetect, searchall
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Currently, we only support local remotes using file URLs, but not local paths. This is a highly requested feature, however, so implement support for local paths as remotes.
First, fix the handling of local paths we already have: the handling of absolute Unix-style paths. Instead of checking for the remote to contain a file URL to determine whether to append "info/lfs" to the URL, look to see if the URL we're using is a file URL, which will catch local paths which will have been rewritten as such by this point.
If we get something that looks like it's not a URL, check if it's a file on the file system, and if so, don't attempt to interpret it as an SSH URL. This fixes the confusion with Windows paths, which resemble SSH-style locations with a single-letter alias as the host name.
Finally, when turning a local path into a file URL, turn the path into an absolute one if possible and rewrite it using slashes, which is required for file URLs. Add several tests for the various cases: one for Unix-style paths, one for native paths, and one for relative paths.
Fixes #3914.