PRs that have open dependencies are not closed automatically when merged locally #6742

New Issue

GiteaMirror · 2025-11-02T07:05:13-06:00

GiteaMirror commented

2025-11-02 07:05:13 -06:00

Originally created by @MathJoDE on GitHub (Jan 24, 2021).

Gitea version (or commit ref): 1.13.1
Git version: 2.11.0
Operating system: Debian Stretch
Database (use [x]):
- PostgreSQL
- 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
- 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

Originally created by @MathJoDE on GitHub (Jan 24, 2021).   - 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) 1. create a PR and an issue 2. add the issue as depenency to the PR 3. 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

GiteaMirror added the type/enhancement label 2025-11-02 07:05:13 -06:00

GiteaMirror commented

2025-11-02 07:05:13 -06:00

@MathJoDE commented on GitHub (Jan 24, 2021):

Edit: added the internal system information of our gitea server (although I guess they have no impact on this issue).

@MathJoDE commented on GitHub (Jan 24, 2021): Edit: added the internal system information of our gitea server (although I guess they have no impact on this issue).

GiteaMirror commented

2025-11-02 07:05:13 -06:00

@delvh commented on GitHub (Jan 24, 2021):

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.

@delvh commented on GitHub (Jan 24, 2021): 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.

GiteaMirror commented

2025-11-02 07:05:14 -06:00

@MathJoDE commented on GitHub (Jan 24, 2021):

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.

@MathJoDE commented on GitHub (Jan 24, 2021): 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. ![Screenshot_20210124_163337](https://user-images.githubusercontent.com/59893632/105635208-2a097180-5e62-11eb-80cf-ff00d1c8c1d3.png)

GiteaMirror commented

2025-11-02 07:05:14 -06:00

@delvh commented on GitHub (Jan 24, 2021):

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.

@delvh commented on GitHub (Jan 24, 2021): 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.

GiteaMirror commented

2025-11-02 07:05:14 -06:00

@zeripath commented on GitHub (Jan 24, 2021):

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)."

@zeripath commented on GitHub (Jan 24, 2021): 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)."

GiteaMirror commented

2025-11-02 07:05:14 -06:00

@MathJoDE commented on GitHub (Jan 24, 2021):

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

@MathJoDE commented on GitHub (Jan 24, 2021): > 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

GiteaMirror commented

2025-11-02 07:05:15 -06:00

@septatrix commented on GitHub (Sep 15, 2021):

Another reason for merging locally is the ability to use different merge algorithms and drivers

@septatrix commented on GitHub (Sep 15, 2021): Another reason for merging locally is the ability to use different merge algorithms and drivers

GiteaMirror commented

2025-11-02 07:05:15 -06:00

@InExtremaRes commented on GitHub (May 19, 2024):

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 <gitea@fake.local>" 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.

@InExtremaRes commented on GitHub (May 19, 2024): 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 \<gitea@fake.local>" 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6742