Skip to content

Comments

fix(lfs): Use full OID in relative path#36611

Draft
fwag wants to merge 2 commits intogo-gitea:mainfrom
fwag:bugfix/full_lfs_oid
Draft

fix(lfs): Use full OID in relative path#36611
fwag wants to merge 2 commits intogo-gitea:mainfrom
fwag:bugfix/full_lfs_oid

Conversation

@fwag
Copy link

@fwag fwag commented Feb 13, 2026

The RelativePath function was truncating the LFS OID when constructing the path. This caused incompatibility with the git-lfs standard, which expects the full, untruncated OID.

This issue could prevent server-side hooks, such as git lfs fsck, from functioning correctly.

This commit aligns Gitea's LFS implementation with the git-lfs standard by using the full OID in the file path. The tests have been updated to reflect this correction.

The `RelativePath` function was truncating the LFS OID when constructing the path. This caused incompatibility with the `git-lfs` standard, which expects the full, untruncated OID.

This commit aligns Gitea's LFS implementation with the `git-lfs` standard by using the full OID in the file path. The tests have been updated to reflect this correction.
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Feb 13, 2026
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label Feb 13, 2026
@fwag
Copy link
Author

fwag commented Feb 13, 2026

@lunny, is there a reason why you used the truncated version of the OID?

How can a migration script be created to convert existing LFS objects?
I have added a doctor check service for the time being.

@fwag fwag marked this pull request as draft February 13, 2026 11:56
The LFS object path generation was previously incorrect, using a truncated OID. This caused incompatibility with standard `git-lfs` tools like `git lfs fsck`.

This commit corrects the path generation to use the full OID.

To avoid breaking existing Gitea instances, read operations (`Get`, `Exists`, `Verify`) are now backward-compatible. They will check for LFS objects at the new path first, and fall back to the old path if the object is not found. New objects are always written to the new path.

Additionally, a new doctor command `lfs-migrate-object-paths` is introduced. This allows administrators to migrate existing LFS objects from the old, incorrect path structure to the new, correct one.
@lunny
Copy link
Member

lunny commented Feb 13, 2026

I don't think git lfs fsck could work normally in Gitea's managed repositories. The lfs objects could be a S3 compatible storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. modifies/go Pull requests that update Go code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants