gitea
gitea copied to clipboard
go-gitea
PRs that have open dependencies are not closed automatically when merged locally
- Gitea version (or commit ref): 1.13.1
- Git version: 2.11.0
- Operating system: Debian Stretch
- Database (use
[x]):- [ ] PostgreSQL
- [x] MySQL
- [ ] MSSQL
- [ ] SQLite
- Can you reproduce the bug at https://try.gitea.io:
- [ ] Yes (provide example URL) https://try.gitea.io/MathJo/Merge_dependency_test/pulls/3
- [x] No, since currently adding dependencies whyever does not work there. (Current gitea version on try.gitea.io:
1.14.0+dev-598-g4acb499f3).
- Log gist:
Description (steps to reproduce)
- create a PR and an issue
- add the issue as depenency to the PR
- merge the branch locally into master, then
git push
Result: a) PR still open in gitea b) the commit and changed files tabs are "N/A"
(If you want to go further: 4. close the dependency issue 5. merge the PR over the UI --> 500 internal server error, but the PR is closed now.)
Screenshots
I'll add one if adding dependencies on try.gitea.io works
Edit: added the internal system information of our gitea server (although I guess they have no impact on this issue).
Well, is that really a bug? The point of PRs is that it should not be merged locally, but remotely (after having given others the option to review it). If you open a PR, you normally expect it to be answered using some kind of UI on the git hosting system. If you locally merge a branch, not only do you ignore the purpose of PRs, no, you go beyond what Gitea's PRs are designed for. Pull requests are not a built-in feature of git, they are provided by the git hosting system like GitHub, GitLab or Gitea. If you manually override them, do as you like, but I'd argue that it is in that case your own responsibility to clean up behind yourself.
I'm not a professional git developer, so I can't judge whether this is abuse of PRs or not. However, an advantage of merging locally I experienced is that Gitea sometimes sees conflicts (and thus prevents merging), while git locally does resolve these conflicts automatically without requiring manual intervention.
Independently of that, Gitea (try.gitea.io) has even a prominently placed guide how to merge PRs locally.
Well, let's consider the following case that can be encountered in most bigger projects:
You open a PR in branch test for branch master.
Master has branch-protection strictly turned on, meaning that no one can commit anything there - PRs are excluded from that.
You have a merge conflict between test and master, so you merge locally as you suggested.
How do you want to push the local master into the remote master?
As intended, it is impossible to commit anything into the master branch.
Now your method fails, as expected.
The correct approach would be to commit the merge from master into your branch test and push that commit, where you can then merge the PR.
have you reported this: " No, since currently adding dependencies whyever does not work there. (Current gitea version on try.gitea.io: 1.14.0+dev-598-g4acb499f3)."
have you reported this: " No, since currently adding dependencies whyever does not work there. (Current gitea version on try.gitea.io: 1.14.0+dev-598-g4acb499f3)."
Done. #14449
Another reason for merging locally is the ability to use different merge algorithms and drivers
There is yet another reason for merging locally: if you want every single commit signed with a key you personally trust.
It's true that you can configure the internal Gitea user to sign its own commits and you can import and trust that public key to your local GPG keyring, but maybe you don't want to expose a commit made by "Gitea <[email protected]>" or you don't want to trust its public key. Even more, maybe you don't have control over the gitea instance and the Gitea user doesn't have a public key and cannot sign the merge commit itself; if you have a branch protection in place, then gitea will refuse to merge since it can't sign, leaving you with the only option of merging locally and sign yourself.
