Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mwaddoups opened this issue May 23, 2025 · 3 comments
Open
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail type/bug

Comments

@mwaddoups
Copy link

mwaddoups commented 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

@mwaddoups
Copy link
Author

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.

@wxiaoguang
Copy link
Contributor

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

@wxiaoguang
Copy link
Contributor

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

@wxiaoguang wxiaoguang added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail type/bug
Projects
None yet
Development

No branches or pull requests

2 participants