Gitea migration clears valid SHA-256 pull-request commit IDs

Gitea Version

v1.27.3, commit 146cc3eec57174711eac0e0a0c7b38670c6e3922

What happened?

The pull-request migration safety check validates commit IDs with git.Sha1ObjectFormat even when the source repository uses Git's SHA-256 object format. A valid SHA-256 pull request therefore has its head, base, and merge commit IDs cleared; the migration record is marked safe and the migration continues.

For an open pull request from a fork, the missing head can then be filled from the current source branch tip. The migrated pull request can consequently refer to a different commit from the one represented by the source API snapshot.

The attached test creates a valid two-commit SHA-256 repository, verifies it with git fsck --full, and compares the SHA-256 result with a SHA-1 control.

How are you running Gitea?

The reproducer runs the migration helper from a clean Gitea v1.27.3 source checkout with the repository's Go test package. It does not require a running Gitea server or a database. Git is used only to create and verify the source fixture.

Steps to reproduce

git clone --branch v1.27.3 --depth 1 https://github.com/go-gitea/gitea.git gitea-v1.27.3
test "$(git -C gitea-v1.27.3 rev-parse HEAD)" = \
  146cc3eec57174711eac0e0a0c7b38670c6e3922

GITEA_DIR="$PWD/gitea-v1.27.3" \
  ./attachments/reproduce.sh gitea-sha256-pr-run

The expected SHA-256 case reports that all three IDs were cleared and that the migration object was marked checked. The SHA-1 control preserves all three IDs. The full source analysis and output are in report.md and attachments.zip.

Expected behavior

A successful migration should preserve the source pull request's head, base, and merge commit identities, or report that the source object format cannot be migrated. It should not mark a record safe after silently discarding those identities.

Attachments

detailed report.md

attachments.zip