With "Autodetect manual merge" enabled, an empty pull request (one with
no commits of its own, for example opened to discuss a branch) was
closed as manually merged as soon as it was checked. Its head commit is
already an ancestor of the base branch, so the detection took the
"fast-forwarded" path and recorded the head itself as the merge commit,
even though nothing was merged.
Detection now skips a PR whose head commit is its merge base, the same
condition Gitea already uses to show a PR as "already included in the
target branch". Real manual merges are still detected, including when
the base branch and the PR branch are pushed together.
The merge base is refreshed on recheck, so a fast-forward manual merge
whose merge base was already refreshed to the head is not detected
either. This only misses a detection and never closes a PR wrongly;
telling the two apart would need a value stored at PR creation.
Fixes https://github.com/go-gitea/gitea/issues/31947
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
In manual merge detected changes, the pushing user should be the
de-facto author of the merge, not the committer. For ff-only merges, the
author (PR owner) often have nothing to do with the merger. Similarly,
even if a merge commit exists, it does not indicate that the merge
commit author is the merger. This is especially true if the merge commit
is a ff-only merge on a given branch.
If pusher is for some reason unavailable, we fall back to the old method
of using committer or owning organization as the author.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Mitrahsoftandwxiaoguang
Lunny Xiao
Adam Majerandwxiaoguang