Open IT-AlexKor opened 2 years ago
- Merge branch 1 to master externally (not from UI) and push changes to Gitea
- Set for PR 1 Mark that it was merged manually and set appropriated commit hash
- 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 ...
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
Thanks for reply.
But I don't understand few things (maybe I don't have enough info about logic):
- 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)
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?
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.
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?
Database
PostgreSQL