Support remote.name.pushurl correctly to fix #945 #949
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
Also support separate remote.name.lfspushurl and global lfs.pushurl to support asymmetrical pull/push in all cases
| @@ -51,7 +51,8 @@ func getCredsForAPI(req *http.Request) (Creds, error) { | |||
| } | |||
|
|
|||
| func getCredURLForAPI(req *http.Request) (*url.URL, error) { | |||
| apiUrl, err := Config.ObjectUrl("") | |||
There was a problem hiding this comment.
I dropped ObjectUrl because it seems defunct except for this check, where it doesn't even use an oid. Seems it's just looking for a base api url to look up the creds for and Endpoint does that.
technoweenie
added a commit
that referenced
this pull request
Jan 29, 2016
Support remote.name.pushurl correctly to fix #945
|
Thanks for tackling this! I tend to forget |
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
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.
Fixes #945
Right now git-lfs ignores the use of 'remote.[name].pushurl' in asymmetrical pull/push situations (within a single remote). This PR changes the way Endpoints are built so that the operation ("download" or "upload") is taken into account and the pushurl is used as a basis instead of the url when pushing. This avoids git-lfs behaving inconsistently with Git itself & the resulting confusion.
Also add support for 'remote.[name].lfspushurl' and global 'lfs.pushurl' so that push versions of urls are supported everywhere you might configure them.
This also affects the Access flags which are stored & looked up alongside the correct url based on whether you're pulling or pushing, in case the 2 urls have different auth mechanisms.