You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been porting repositories from a legacy Gitlab instance, and have had no issues except for one particular repository. This repo could not be directly migrated by Gitea; the raw Gitlab repos (*.git) were dropped into the appropriate owner directory on Gitea and successfully adopted by Gitea using the documented process. Everything looks great and the repo can be successfully cloned over HTTP or SSH.
However, any sort of push operation (commit, branch delete) results in a panic from an "invalid memory address or nil pointer dereference." The gist includes three different panic origins and their stack traces.
The repo in particular has a few large binary blobs, 17 branches, 630 commits, 235 tags, and occupies 58 MiB. I will note that the ".pack" file under objects/pack occupies 79553430 bytes. We're willing to prune out old commits and branches, but would have to do that off Gitea since push is currently broken, if that is our only option.
I would attempt to reproduce it on the Gitea demo site but the repo contains proprietary IP.
Rocky Release 9.3 with SELinux enabled, Red Hat Server Level 1 Security Profile
How are you running Gitea?
I have tried the downloaded 1.22.0 binary (gitea_1.22.0_dev-1092-g02d4a62e3) along with the nightly build (1.22.0+41-g3fcf865a4b). Gitea is running on a Hyper-V hosted VM (no container), launched as a systemd service (service file included in gist).
Database
MySQL/MariaDB
The text was updated successfully, but these errors were encountered:
Backport #31333 by @lunnyFix#31330Fix#31311
A workaround to fix the old database is to update object_format_name to
`sha1` if it's empty or null.
Co-authored-by: Lunny Xiao <[email protected]>
go-gitea
locked as resolved and limited conversation to collaborators
Sep 10, 2024
Fix adopt repository has empty object name in database (go-gitea#31333)
Fixgo-gitea#31330Fixgo-gitea#31311
A workaround to fix the old database is to update object_format_name to
`sha1` if it's empty or null.
(cherry picked from commit 1968c22)
With tests services/repository/adopt_test.go
(cherry picked from commit 8efef06)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
We have been porting repositories from a legacy Gitlab instance, and have had no issues except for one particular repository. This repo could not be directly migrated by Gitea; the raw Gitlab repos (*.git) were dropped into the appropriate owner directory on Gitea and successfully adopted by Gitea using the documented process. Everything looks great and the repo can be successfully cloned over HTTP or SSH.
However, any sort of push operation (commit, branch delete) results in a panic from an "invalid memory address or nil pointer dereference." The gist includes three different panic origins and their stack traces.
The repo in particular has a few large binary blobs, 17 branches, 630 commits, 235 tags, and occupies 58 MiB. I will note that the ".pack" file under objects/pack occupies 79553430 bytes. We're willing to prune out old commits and branches, but would have to do that off Gitea since push is currently broken, if that is our only option.
I would attempt to reproduce it on the Gitea demo site but the repo contains proprietary IP.
Thank you!
Gitea Version
1.22.0+41-g3fcf865a4b
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/gmaxwell447/b45ee124ad25e04bdc39619a254d6247
Screenshots
No response
Git Version
2.39.3
Operating System
Rocky Release 9.3 with SELinux enabled, Red Hat Server Level 1 Security Profile
How are you running Gitea?
I have tried the downloaded 1.22.0 binary (gitea_1.22.0_dev-1092-g02d4a62e3) along with the nightly build (1.22.0+41-g3fcf865a4b). Gitea is running on a Hyper-V hosted VM (no container), launched as a systemd service (service file included in gist).
Database
MySQL/MariaDB
The text was updated successfully, but these errors were encountered: