4 Commits (9c990ac043a0167dc59f1c822988ed2316f7c1df)

Author	SHA1	Message	Date
Giteabot	6203ae764a	Distinguish LFS object errors to ignore missing objects during migration (#31702) (#31745) ... Backport #31702 by @wolfogre Fix #31137. Replace #31623 #31697. When migrating LFS objects, if there's any object that failed (like some objects are losted, which is not really critical), Gitea will stop migrating LFS immediately but treat the migration as successful. This PR checks the error according to the [LFS api doc](https://github.com/git-lfs/git-lfs/blob/main/docs/api/batch.md#successful-responses). > LFS object error codes should match HTTP status codes where possible: > > - 404 - The object does not exist on the server. > - 409 - The specified hash algorithm disagrees with the server's acceptable options. > - 410 - The object was removed by the owner. > - 422 - Validation error. If the error is `404`, it's safe to ignore it and continue migration. Otherwise, stop the migration and mark it as failed to ensure data integrity of LFS objects. And maybe we should also ignore others errors (maybe `410`? I'm not sure what's the difference between "does not exist" and "removed by the owner".), we can add it later when some users report that they have failed to migrate LFS because of an error which should be ignored. Co-authored-by: Jason Song <i@wolfogre.com>	7 months ago
Lunny Xiao	25b842df26	Move get/set default branch from git package to gitrepo package to hide repopath (#29126)	12 months ago
wxiaoguang	5cddab4f74	Make wiki default branch name changable (#29603) ... Fix #29000 Fix #28685 Fix #18568 Related: #27497 And by the way fix #24036, add a Cancel button there (one line)	12 months ago
Lunny Xiao	58ce1de994	Move migration functions to services layer (#29497)	1 year ago