github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Open
opened 2025-11-02 08:21:48 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-02 08:21:48 -06:00
Owner
Copy Link

Originally created by @IT-AlexKor on GitHub (Apr 27, 2022).

Originally assigned to: @a1012112796 on GitHub.

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

Originally created by @IT-AlexKor on GitHub (Apr 27, 2022). Originally assigned to: @a1012112796 on GitHub. ### 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
GiteaMirror added the type/question label 2025-11-02 08:21:48 -06:00
GiteaMirror commented 2025-11-02 08:21:49 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (May 9, 2022):

  1. Merge branch 1 to master externally (not from UI) and push changes to Gitea
  2. Set for PR 1 Mark that it was merged manually and set appropriated commit hash
  3. 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: https://github.com/go-gitea/gitea/pull/12543

@a1012112796 commented on GitHub (May 9, 2022): > 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: https://github.com/go-gitea/gitea/pull/12543
GiteaMirror commented 2025-11-02 08:21:49 -06:00
Author
Owner
Copy Link

@IT-AlexKor commented on GitHub (May 9, 2022):

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
before_merge

git14 merged with auto-merge enabled
git14merged_with_automerge

git15 merged without auto-merge, wihtour merge commit
git15merged_no_automerge_commitnotset

git15 merged without auto-merge, merge commit is set
git15merged_no_automerge_commitset

commit graph
commitgraph

@IT-AlexKor commented on GitHub (May 9, 2022): 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** ![before_merge](https://user-images.githubusercontent.com/101557941/167396331-a21fed37-2f87-4378-90d1-b2dad1509c47.png) **git14 merged with auto-merge enabled** ![git14merged_with_automerge](https://user-images.githubusercontent.com/101557941/167396349-5682a5cd-fdf8-4435-ba0a-6a1b423c2206.png) **git15 merged without auto-merge, wihtour merge commit** ![git15merged_no_automerge_commitnotset](https://user-images.githubusercontent.com/101557941/167396391-57c475bf-8ab9-41a5-ad53-f6218011a84b.png) **git15 merged without auto-merge, merge commit is set** ![git15merged_no_automerge_commitset](https://user-images.githubusercontent.com/101557941/167396421-aac02f31-0932-4792-a916-4fde6093ebf4.png) **commit graph** ![commitgraph](https://user-images.githubusercontent.com/101557941/167396452-99ea5f84-8dd9-4c6c-b3f2-3ccb5f3fd48d.png)
GiteaMirror commented 2025-11-02 08:21:49 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (May 9, 2022):

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 commented on GitHub (May 9, 2022): > 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](https://git-scm.com/docs/git-merge-base))
GiteaMirror commented 2025-11-02 08:21:49 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (May 9, 2022):

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?

@a1012112796 commented on GitHub (May 9, 2022): 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?
GiteaMirror commented 2025-11-02 08:21:50 -06:00
Author
Owner
Copy Link

@IT-AlexKor commented on GitHub (May 9, 2022):

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.
@IT-AlexKor commented on GitHub (May 9, 2022): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#8875
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?