[gitlab to gitea] migration from gitlab creates inaccessible pull requests #14522

New Issue

GiteaMirror · 2025-11-02T11:15:11-06:00

GiteaMirror commented

2025-11-02 11:15:11 -06:00

Originally created by @mwaddoups on GitHub (May 23, 2025).

Description

I am looking at migrating from a gitlab.com hosted private gitlab repo. Gitea looks awesome and we're keen to use it.

Our workflow there is that we create a branch for a merge request, and delete the branch on merge, squash commits and create a single new commit on the main branch (by rebasing). Some of our older MRs may have had a separate merge commit.

This is a brand new gitea install on Debian 12, installation from binary.

When I go to migrate that repository into gitea, all data imports fine - but trying to open any of the imported merged PR's gives a 500 internal server error.

GetRefCommitID, object does not exist [id: refs/pull/19/head, rel_path: ]

This has been the case with a few different repos that I have tried so is unlikely to be specific to the one repository.

Is this expected behaviour with the branches being deleted? Gitlab is still able to show the diff - I suspect it points at the merged commit afterwards.

Gitea Version

1.23.8

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.39.5

Operating System

Debian 12

How are you running Gitea?

Followed the binary installation steps, just ran from command line for this test.

Database

SQLite

Originally created by @mwaddoups on GitHub (May 23, 2025). ### Description I am looking at migrating from a gitlab.com hosted private gitlab repo. Gitea looks awesome and we're keen to use it. Our workflow there is that we create a branch for a merge request, and delete the branch on merge, squash commits and create a single new commit on the main branch (by rebasing). Some of our older MRs may have had a separate merge commit. This is a brand new gitea install on Debian 12, installation from binary. When I go to migrate that repository into gitea, all data imports fine - but trying to open any of the imported merged PR's gives a 500 internal server error. `GetRefCommitID, object does not exist [id: refs/pull/19/head, rel_path: ]` This has been the case with a few different repos that I have tried so is unlikely to be specific to the one repository. Is this expected behaviour with the branches being deleted? Gitlab is still able to show the diff - I suspect it points at the merged commit afterwards. ### Gitea Version 1.23.8 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.39.5 ### Operating System Debian 12 ### How are you running Gitea? Followed the binary installation steps, just ran from command line for this test. ### Database SQLite

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 11:15:11 -06:00

GiteaMirror closed this issue

2025-11-02 11:15:11 -06:00

GiteaMirror commented

2025-11-02 11:15:12 -06:00

@mwaddoups commented on GitHub (May 27, 2025):

An update on this.

The issue is that refs/pull//head is not created for the MRs I've imported automatically from Gitlab.

I expect this is the same issue as here https://codeberg.org/forgejo/forgejo/issues/6819 . Based on their work, I also suspect it may only affect older Gitlab repos - I haven't had a detailed go at replication on newly created Gitlab repos.

A workaround is to create the ref files manually by copying the merge_commit_sha field from the pull request API into a git ref for the relevant repo at pull//head. A bash script which does this for all merge requests with null head sha (requires jq):

# !/bin/bash
#

GITEA_URL="http://<user>:<pass>@<your gitea url>/api/v1/repos/"
GITEA_DATA="/var/lib/gitea/"
GITEA_REPO="<your org name>/<your repo>"

curl -X GET --url "${GITEA_URL}${GITEA_REPO}/pulls" | jq -c '.[] | select( .head.sha == "" ) | [.merge_commit_sha, .number]' | while read i; do
        commit_sha=$(echo $i | jq -r '.[0]')
        pr_number=$(echo $i | jq -r '.[1]')
        dir_name=${GITEA_DATA}/data/gitea-repositories/${GITEA_REPO}.git/refs/pull/$pr_number

        if [ ! -d $dir_name ]; then
                echo "Creating missing $dir_name/head..."
                mkdir $dir_name
                echo "$commit_sha" > $dir_name/head 
        fi
done

echo "All done!"

After this all looks good on import.

@mwaddoups commented on GitHub (May 27, 2025): An update on this. The issue is that refs/pull/<x>/head is not created for the MRs I've imported automatically from Gitlab. I expect this is the same issue as here https://codeberg.org/forgejo/forgejo/issues/6819 . Based on their work, I also suspect it may only affect older Gitlab repos - I haven't had a detailed go at replication on newly created Gitlab repos. A workaround is to create the ref files manually by copying the `merge_commit_sha` field from the pull request API into a git ref for the relevant repo at pull/<pr number>/head. A bash script which does this for all merge requests with null head sha (requires `jq`): ``` # !/bin/bash # GITEA_URL="http://<user>:<pass>@<your gitea url>/api/v1/repos/" GITEA_DATA="/var/lib/gitea/" GITEA_REPO="<your org name>/<your repo>" curl -X GET --url "${GITEA_URL}${GITEA_REPO}/pulls" | jq -c '.[] | select( .head.sha == "" ) | [.merge_commit_sha, .number]' | while read i; do commit_sha=$(echo $i | jq -r '.[0]') pr_number=$(echo $i | jq -r '.[1]') dir_name=${GITEA_DATA}/data/gitea-repositories/${GITEA_REPO}.git/refs/pull/$pr_number if [ ! -d $dir_name ]; then echo "Creating missing $dir_name/head..." mkdir $dir_name echo "$commit_sha" > $dir_name/head fi done echo "All done!" ``` After this all looks good on import.

GiteaMirror commented

2025-11-02 11:15:12 -06:00

@wxiaoguang commented on GitHub (May 27, 2025):

Have you tried Gitea 1.24? I think the problem might have been fixed.

@wxiaoguang commented on GitHub (May 27, 2025): Have you tried Gitea 1.24? I think the problem might have been fixed.

GiteaMirror commented

2025-11-02 11:15:12 -06:00

@wxiaoguang commented on GitHub (May 27, 2025):

I can confirm the problem should have been fixed in 1.24

For example, after I manually deleted the ref of pull#1:

git update-ref -d refs/pull/1/head

The page still renders correctly:

@wxiaoguang commented on GitHub (May 27, 2025): I can confirm the problem should have been fixed in 1.24 For example, after I manually deleted the ref of `pull#1`: ``` git update-ref -d refs/pull/1/head ``` The page still renders correctly: ![Image](https://github.com/user-attachments/assets/dbbb8230-f4c1-49f7-8f96-f356ec8781df)

GiteaMirror commented

2025-11-02 11:15:13 -06:00

@lunny commented on GitHub (Jun 5, 2025):

Which GitLab repository have you tried to migrate?

@lunny commented on GitHub (Jun 5, 2025): Which GitLab repository have you tried to migrate?

GiteaMirror commented

2025-11-02 11:15:13 -06:00

@mwaddoups commented on GitHub (Jun 7, 2025):

Apologies for being slow getting back to you.

I can confirm it's no longer an issue in 1.24. Unfortunately (much like the linked issue), the effected repo is an old, private repo that I can't share and I can't replicate the exact problem with a new one. Sorry I can't be more help.

But - all looks good on the new version - and thanks for your help and time both!

@mwaddoups commented on GitHub (Jun 7, 2025): Apologies for being slow getting back to you. I can confirm it's no longer an issue in 1.24. Unfortunately (much like the linked issue), the effected repo is an old, private repo that I can't share and I can't replicate the exact problem with a new one. Sorry I can't be more help. But - all looks good on the new version - and thanks for your help and time both!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14522