fix: short-circuit to avoid rebasing (#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.

Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8622
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
This commit is contained in:
Gusted 2025-07-23 07:30:30 +02:00 committed by Earl Warren
commit f3ccfc4969
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