Refactor "Content" for file uploading (#25851)

Before: the concept "Content string" is used everywhere. It has some
problems:

1. Sometimes it means "base64 encoded content", sometimes it means "raw
binary content"
2. It doesn't work with large files, eg: uploading a 1G LFS file would
make Gitea process OOM

This PR does the refactoring: use "ContentReader" / "ContentBase64"
instead of "Content"

This PR is not breaking because the key in API JSON is still "content":
`` ContentBase64 string `json:"content"` ``
This commit is contained in:
wxiaoguang 2023-07-19 02:14:47 +08:00 committed by GitHub
parent 265a28802a
commit 236c645bf1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
15 changed files with 103 additions and 80 deletions

View file

@ -16125,7 +16125,7 @@
"content": {
"description": "new or updated file content, must be base64 encoded",
"type": "string",
"x-go-name": "Content"
"x-go-name": "ContentBase64"
},
"from_path": {
"description": "old path of the file to move",
@ -16810,7 +16810,7 @@
"content": {
"description": "content must be base64 encoded",
"type": "string",
"x-go-name": "Content"
"x-go-name": "ContentBase64"
},
"dates": {
"$ref": "#/definitions/CommitDateOptions"
@ -21687,7 +21687,7 @@
"content": {
"description": "content must be base64 encoded",
"type": "string",
"x-go-name": "Content"
"x-go-name": "ContentBase64"
},
"dates": {
"$ref": "#/definitions/CommitDateOptions"