Disallow merging if PR has been rejected #2245

New Issue

GiteaMirror · 2025-11-02T04:29:17-06:00

GiteaMirror commented

2025-11-02 04:29:17 -06:00

Originally created by @FryDay on GitHub (Aug 24, 2018).

If you request changes on a PR, you are still able to merge it. Github disallows merging if a PR is rejected.

Originally created by @FryDay on GitHub (Aug 24, 2018). If you request changes on a PR, you are still able to merge it. Github disallows merging if a PR is rejected.

GiteaMirror added the issue/duplicate label 2025-11-02 04:29:17 -06:00

GiteaMirror closed this issue

2025-11-02 04:29:17 -06:00

GiteaMirror commented

2025-11-02 04:29:18 -06:00

@lafriks commented on GitHub (Aug 24, 2018):

Was not there issue already about this?

@lafriks commented on GitHub (Aug 24, 2018): Was not there issue already about this?

GiteaMirror commented

2025-11-02 04:29:19 -06:00

@FryDay commented on GitHub (Aug 24, 2018):

Not that I was able to find.

@FryDay commented on GitHub (Aug 24, 2018): Not that I was able to find.

GiteaMirror commented

2025-11-02 04:29:19 -06:00

@lunny commented on GitHub (Aug 25, 2018):

@FryDay I think a PR is rejected by someone could still be merged on Github.

@lunny commented on GitHub (Aug 25, 2018): @FryDay I think a PR is rejected by someone could still be merged on Github.

GiteaMirror commented

2025-11-02 04:29:19 -06:00

@FryDay commented on GitHub (Aug 26, 2018):

Only someone with admin privileges, and you need to click through warnings to do it.

@FryDay commented on GitHub (Aug 26, 2018): Only someone with admin privileges, and you need to click through warnings to do it.

GiteaMirror commented

2025-11-02 04:29:19 -06:00

@lunny commented on GitHub (Aug 27, 2018):

@FryDay yes, we could follow that.

@lunny commented on GitHub (Aug 27, 2018): @FryDay yes, we could follow that.

GiteaMirror commented

2025-11-02 04:29:19 -06:00

@stale[bot] commented on GitHub (Jan 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:29:20 -06:00

@stale[bot] commented on GitHub (Feb 21, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 21, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror commented

2025-11-02 04:29:20 -06:00

@3l73 commented on GitHub (Apr 15, 2019):

AFAIK the reject information stored inside of a review, that is connected to a comment.

In order to disable a pull request, all comments of an issue have to be process, checking if the rejection is still valid.
This solution become a problem depending on the amount of comments.

One possible solution could be changing the relation between comment and review to issue and review.
This solution could lead to

a better runtime (less entries inside a loop)
a listing who reject a pull request
- this could be used to remove reject status by an administrator
possibility to create a rule that a review is required in order to merge

@3l73 commented on GitHub (Apr 15, 2019): AFAIK the reject information stored inside of a review, that is connected to a comment. In order to disable a pull request, all comments of an issue have to be process, checking if the rejection is still valid. This solution become a problem depending on the amount of comments. One possible solution could be changing the relation between comment and review to issue and review. This solution could lead to 1. a better runtime (less entries inside a loop) 2. a listing who reject a pull request - this could be used to remove reject status by an administrator 3. possibility to create a rule that a review is required in order to merge

GiteaMirror commented

2025-11-02 04:29:21 -06:00

@3l73 commented on GitHub (Apr 15, 2019):

Based on the solution described in the previous comment, there is a way with less refactoring.

The issue is extended with the review, the review remain inside the comment.
The issue indexer process the comments and create the review inside the issue based on the information inside the comment.

Did not know how often the indexer is running and how long it will take to process the data.

@3l73 commented on GitHub (Apr 15, 2019): Based on the solution described in the previous comment, there is a way with less refactoring. The issue is extended with the review, the review remain inside the comment. The issue indexer process the comments and create the review inside the issue based on the information inside the comment. Did not know how often the indexer is running and how long it will take to process the data.

GiteaMirror commented

2025-11-02 04:29:21 -06:00

@3l73 commented on GitHub (Apr 21, 2019):

I will have a look inside this issue.

Other issues going in the same direction:

@3l73 commented on GitHub (Apr 21, 2019): I will have a look inside this issue. Other issues going in the same direction: - #3588 - #996

GiteaMirror commented

2025-11-02 04:29:22 -06:00

@lunny commented on GitHub (Sep 12, 2019):

duplicated with #3588

@lunny commented on GitHub (Sep 12, 2019): duplicated with #3588

GiteaMirror referenced this issue