[v12.0/forgejo] fix: rebase and fast forward merge breaks commit signatures (#8624)

**Backport:** https://codeberg.org/forgejo/forgejo/pulls/8622

- Do not try to rebase a pull request when it is zero commits behind. We can trust this number as before merging a repository the status of the pull request is mergeable and thus not in a conflict checking stage (where this would be updated).
- This resolves a issue where `git-replay` would rebase a pull request when this is not needed and causes to lose the signature of Git commits and commit IDs as shown in the pullrequest commits timeline.
- Resolves forgejo/forgejo#8619
- Add a simple integration test that simply checks that after merging a up-to-date pull request via the rebase style that the commit ID didn't change. This demonstrates that it didn't do needlessly rebasing.

Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8624
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
This commit is contained in:
forgejo-backport-action 2025-07-23 10:55:17 +02:00 committed by Earl Warren
commit ac0d653925
2 changed files with 34 additions and 0 deletions

View file

@ -249,6 +249,11 @@ func rebaseTrackingOnToBase(ctx *mergeContext, mergeStyle repo_model.MergeStyle)
ctx.outbuf.Reset()
ctx.errbuf.Reset()
// If the pull request is zero commits behind, then no rebasing needs to be done.
if ctx.pr.CommitsBehind == 0 {
return nil
}
// Check git version for availability of git-replay. If it is available, we use
// it for performance and to preserve unknown commit headers like the
// "change-id" header used by Jujutsu and GitButler to track changes across