merge_base sha changes after merging PR

[mbarinc]

• Gitea version (or commit ref): 1.11.3
• Git version: 2.23
• Operating system: Linux
• Database (use [x]):
  • PostgreSQL
  • [ x ] MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • [ x ] No
  • Not relevant
• Log gist:

Description

Three days ago I've updated the release from 1.11.1 to 1.11.3, and now I've a strange issue.

After merging a PR, number of "commits" and number of "files changed" changes in N/A.
I looked the sha stored in merge_base column on the pull_request table and, after merging, Gitea change it.

In the log I found correctly this insert statement when open the PR:

2020/03/30 19:10:27 .../xorm/session_raw.go:180:exec() [I] [SQL] INSERT INTO `pull_request` (`type`,`status`,`conflicted_files`,`issue_id`,`index`,`head_repo_id`,`base_repo_id`,`head_branch`,`base_branch`,`merge_base`,`has_merged`,`merged_commit_id`,`merger_id`,`merged_unix`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) []interface {}{0, 2, "[]", 2045, 60, 10, 10, "CM/TestFrom", "CM/TestTo", "ccbd85df390ccc216b2db07642f65d03917292b9", false, "", 0, 1585588227} - took: 1.07155ms

But immediately after the merger, mysteriously , I found this update statement that changes the sha:

2020/03/30 19:12:05 .../xorm/session_raw.go:196:exec() [I] [SQL] UPDATE `pull_request` SET `status` = ?, `conflicted_files` = ?, `merge_base` = ?, `merged_unix` = ? WHERE `id`=? []interface {}{2, "[]", "319352dfa93c653c439f8b1a1266ea6899c0a322", 1585588325, 1931} - took: 3.730809ms

Screenshots

[lunny]

This should be a duplicated with #10766