-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raw file API: deprecate {ref} path parameter + allow shortened commit refs #17185
Conversation
the ?ref= param was added recently in go-gitea#14602, and can fully replace the (previously undocumented) ref-prefix of the filepath
we just deprecated this API, but this is a short fix to go-gitea#17179 A more minimal fix would be to check if len(parts) > 1 in line context/repo.go#L698
@@ -413,7 +413,7 @@ func RepoRefForAPI(next http.Handler) http.Handler { | |||
return | |||
} | |||
ctx.Repo.CommitID = ctx.Repo.Commit.ID.String() | |||
} else if len(refName) == 40 { | |||
} else if len(refName) >= 7 && len(refName) <= 40 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt that that will improve the situation.
"Great. Now I cannot even get the README.md".
Maybe it would be better to check whether that file is tracked when the if three lines below is entered before returning the error.
Or do I misunderstand what this is supposed to do?
Regarding the else block below, I am fairly certain that I am misunderstanding something here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think hard-coding the length is a good idea. Maybe git will use SHA256 in future.
https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@delvh no this won't happen, as we check if such a commit exists. If not, getRefName()
falls back to treating the entire thing as a TreePath and returns Repo.DefaultBranch as ref, in which case we don't enter this if-clause at all.
@wxiaoguang this is all over the codebase, definitily a different issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can introduce a function like IsPossibleGitCommit
and use it from now on. It's easier to understand and maintain.
Maybe we should have a break change. |
Answering to your question shortened commit sha was added because of support needed for pkg.go.dev As for API I did not see need for it as for API you will usually work with full commit sha As for legacy urls we should drop support for them imho, it's been quite some time already |
@lunny Aesthetically I too prefer the {ref} path parameter, but
|
regarding the CI fail in
well.. the ref param isn't required. is there a workaround wrt the linter? (It dawns upon me that this is the reason this param was never documented..) |
...when path contains no hash-path-separator ('/') This is a workaround to go-gitea#17179. Entering this case when `path` does not contain a '/' does not really make sense, as that means the tree path is empty, but this case is only entered for routes that expect a non-empty tree path. Treepaths like <40-char-dirname>/<filename> will still fail, but hopefully don't occur that often. A more complete fix that avoids this case too is outlined in go-gitea#17185, but too big of a change to backport
...when path contains no hash-path-separator ('/') This is a workaround to #17179. Entering this case when `path` does not contain a '/' does not really make sense, as that means the tree path is empty, but this case is only entered for routes that expect a non-empty tree path. Treepaths like <40-char-dirname>/<filename> will still fail, but hopefully don't occur that often. A more complete fix that avoids this case too is outlined in #17185, but too big of a change to backport
Please resolve the conflicts. |
Is this PR active? |
It has been stale for a long time and I can't think of a way to handling it other than closing it. Feel free to reopen if there's any new progress and I could also help. |
The fix could be like this: Refactor RepoRefByType #32413 |
Looking into #17179 I noticed a couple oddities with the raw file API:
{repo_api_url}/raw/{ref}/{tree_path}
).Parsing this is a mess, see
context/repo.go getRefName()
?ref=
was added in Add support for ref parameter to get raw file API #14602, now providing a duplicate parameter (and a deprecation path! 😄)All this culminates in the weird failure mode of #17179.
This PR aims to fix #17179, but also to find a way out of this mess:
{ref}
path parameter, to fix above bug{ref}
Backporting the actual bugfix is simpler, as mentioned in df834a7