Jason Song 09b56fc069 Distinguish LFS object errors to ignore missing objects during migration (#31702) ... 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.		2024-07-31 10:29:48 +00:00
..
client.go
client_test.go
content_store.go
endpoint.go
endpoint_test.go
filesystem_client.go
http_client.go
http_client_test.go
LICENSE
pointer.go
pointer_scanner_gogit.go
pointer_scanner_nogogit.go
pointer_test.go
shared.go
transferadapter.go
transferadapter_test.go