Different behavior of "Mark PR as manually merged" and "Autodetect manual merge"

[IT-AlexKor]

Description

Main problem - after extranl merge I can't see any changes in PR even if I set it to Manually merged (via UI, not autodetect). I know about feature "Autodetect manual merge", but there is some note that it can misjudge in some special cases , but no details in which one.

While researching about these options, I found a different behavior on how "Mark PR as manually merged" and "Autodetect manual merge" are working. While "Autodetect manual merge" changing the merge_base commit (in pull_request table), option "Mark PR as manually merged" wasn't. I think it's a bug - I can't see any reasons why it shouldn't work. When user from tells Gitea (from UI) in which commit current PR was merged, Gitea can detect merge_base and change it.

Steps to reproduce:

1. Use repo with disabled "Mark PR as manually merged" and "Autodetect manual merge"
2. create 2 branches from master with changes and create PR's for each one
3. Enable "Mark PR as manually merged" in repo
4. Merge branch 1 to master externally (not from UI) and push changes to Gitea
5. Set for PR 1 Mark that it was merged manually and set appropriated commit hash
6. Now PR 1 marked as manually merged and you can't see any changes (commits, files changed) in PR UI, because merge_base wasn't changed
7. Enable "Autodetect manual merge" in repo
8. Merge branch 2 to master externally (not from UI) and push changes to Gitea
9. Now PR 2 marked as manually merged (autodetected) and you can see changes (commits, files changed) in PR UI, because merge_base was changed in DB

Gitea Version

1.16.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.21.0

Operating System

Debian 11.3

How are you running Gitea?

RUN_MODE = prod
APP_NAME = Gitea

[indexer]
REPO_INDEXER_TYPE      = elasticsearch
REPO_INDEXER_PATH      = indexers/repos.bleve
REPO_INDEXER_CONN_STR  = http://<ERASED>:9200/
UPDATE_BUFFER_LEN      = 20
REPO_INDEXER_EXCLUDE   = resources/bin/**
MAX_FILE_SIZE          = 1.048576e+06
ISSUE_INDEXER_NAME     = gitea_issues
ISSUE_INDEXER_PATH     = indexers/issues.bleve
REPO_INDEXER_NAME      = gitea_codes
STARTUP_TIMEOUT        = 30s
ISSUE_INDEXER_TYPE     = elasticsearch
ISSUE_INDEXER_CONN_STR = http://<ERASED>:9200/
REPO_INDEXER_ENABLED   = true

[service]
ENABLE_CAPTCHA                    = false
DEFAULT_ENABLE_TIMETRACKING       = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = false
REQUIRE_SIGNIN_VIEW               = true
REGISTER_EMAIL_CONFIRM            = false
NO_REPLY_ADDRESS                  = noreply.localhost
ENABLE_TIMETRACKING               = false
ENABLE_NOTIFY_MAIL                = true
DISABLE_REGISTRATION              = true
ENABLE_USER_HEATMAP               = false
AUTO_WATCH_NEW_REPOS              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
AUTO_WATCH_ON_CHANGES             = true
DEFAULT_KEEP_EMAIL_PRIVATE        = false

[server]
LFS_JWT_SECRET   = <ERASED>
APP_DATA_PATH    = /data/gitea
SSH_DOMAIN       = <ERASED>
SSH_ROOT_PATH    = /data/git/.ssh
PROTOCOL         = http
HTTP_PORT        = 3000
ROOT_URL         = https://<ERASED>
SSH_LISTEN_PORT  = 22
DISABLE_SSH      = false
OFFLINE_MODE     = false
LFS_START_SERVER = true
SSH_PORT         = 22
ENABLE_PPROF     = false
DOMAIN           = <ERASED>

[log]
ROUTER    = file,console
MODE      = file,console
ROOT_PATH = /data/gitea/log
LEVEL     = trace
DB_TYPE   = postgres

[cron.delete_old_actions]
ENABLED    = true
SCHEDULE   = 0 0 0 * * *
OLDER_THAN = 192h

[mailer]
HOST    = <ERASED>:25
ENABLED = true
FROM    = <ERASED>

[database]
LOG_SQL = true
DB_TYPE = postgres
HOST    = <ERASED>:5432
PASSWD  = <ERASED>
NAME    = gitea_db
CHARSET = utf8
SCHEMA  = public
USER    = gitea

[security]
IMPORT_LOCAL_PATHS = true
DISABLE_GIT_HOOKS  = false
PASSWORD_HASH_ALGO = pbkdf2
INSTALL_LOCK       = true
SECRET_KEY         = <ERASED>
INTERNAL_TOKEN     = <ERASED>

[openid]
ENABLE_OPENID_SIGNUP = false
ENABLE_OPENID_SIGNIN = false

[lfs]
PATH = /data/gitea/lfs

[admin]
DEFAULT_EMAIL_NOTIFICATIONS = onmention

[git.timeout]
MIRROR  = 600
MIGRATE = 600

[mirror]
MIN_INTERVAL = 1m

[repository]
ROOT = /data/git/gitea-repositories

[picture]
DISABLE_GRAVATAR        = false
ENABLE_FEDERATED_AVATAR = true

[session]
PROVIDER = file

[metrics]
ENABLED = true

[oauth2]
JWT_SECRET = <ERASED>

[webhook]
ALLOWED_HOST_LIST = <ERASED>,<ERASED>

[markup.jupyter]
RENDER_COMMAND  = jupyter nbconvert --stdin --stdout --to html --template basic
IS_INPUT_FILE   = false
FILE_EXTENSIONS = .ipynb
ENABLED         = true

[migrations]
ALLOW_LOCALNETWORKS = true
ALLOWED_DOMAINS     = <ERASED>,<ERASED>,<ERASED>

[ui]
ISSUE_PAGING_NUM = 25

Database

PostgreSQL

[a1012112796]

4. Merge branch 1 to master externally (not from UI) and push changes to Gitea
5. Set for PR 1 Mark that it was merged manually and set appropriated commit hash
6. Now PR 1 marked as manually merged and you can't see any changes (commits, files changed) in PR UI, because merge_base wasn't changed

Because after the 4th step, the merge base has been changed, the commits, changed files has becomed empty list also, then when you notify gitea that you has merged the pull request manually, we can do nothing to restore it.

but there is some note that it can misjudge in some special cases , but no details in which one.

if you make the head branch same with base branch (for example: merge base branch to head branch and push head branch). then it will be consider as merge pull request also. It's not wrong but ...

ref: #12543

[IT-AlexKor]

Thanks for reply.

But I don't understand few things (maybe I don't have enough info about logic):

1. Why are you changing merge_base after manual push (without auto-detect)? What will be if you don't?
2. When user manually set "merge commit id", why you didn't try to find latest commit in base_branch before first commit in head_branch (the commit from head_branch was started)?

Sorry if my questions are too simple/stupid - I don't have much deep knowledge of internal git logic...

before merge

git14 merged with auto-merge enabled

git15 merged without auto-merge, wihtour merge commit

git15 merged without auto-merge, merge commit is set

commit graph

[a1012112796]

Thanks for reply.

But I don't understand few things (maybe I don't have enough info about logic):

1. Why are you changing merge_base after manual push (without auto-detect)? What will be if you don't?

the 'merge base' is the Latest comit which is on both head and base branch (common ancestors). so it should be changed when the head or base branch is updated. it will be used for the git diff view. (ref: git-merge-base)

[a1012112796]

Looks something is wrong, will chek it later. In my view, It's really not a good idea to merge a pull request manually, why not do it on ui?

[IT-AlexKor]

We (my team) have deep automation for our development flow. So we work with code via git (from microservice), some actions executed via gitea api, but we merge branches via git.

Previously we use Bitbucket, a month ago we switched to Gitea (great product by the way). The first problem was that our merged PR's was still open after merge. We try to use manual merge, but there was the second problem - after manual merge, the PR's was empty (no changes and commits). Right now we are using branch merge auto-detection, but we are afraid a little about misjudgement. In comparison with BB, it has auto-detection of merge and git diff in UI always presents.

Right now we see few options:

1. merge via git with enabled auto-detection - using right now and it's look like working correctly
2. merge via git with manual merge commit set. Can't use because of different behavior and PR clearance (current topic)
3. use gitea api to merge. It's a last option if other will not work, because we don't want to split code operations from git to git+api level.