Closing a PR should not close linked issues #66741
Replies: 46 comments 48 replies
-
|
Adding myself to this. I would also like to be able to disable auto-closing of issues. I work on PyMuPDF, and we do not want an issue to be marked as fixed until a release has been made that contains the fix. This avoids confusion for users, and simplifies our release process. Projects differ in how they want to handle things like this, so i find it surprising that Github is forcing the same behaviour on all projects, regardless of size or organisation. I don't personally mind what the default behaviour is, but it really needs to be configurable. |
Beta Was this translation helpful? Give feedback.
-
|
I agree this is an important thing for teams. The ability to link a PR without auto-closing it would be a great addition and something our team would definitely find very useful. Not every PR solves an issue completely - perhaps there is QA to do, perhaps there are manual steps, etc. There are many cases I can think of where the issue shouldn't be closed immediately and this should be the only option.
|
Beta Was this translation helpful? Give feedback.
-
|
Just throwing another comment in for support of this, I can't believe that GitHub is so prescriptive with this, expecting that everyone wants to close a linked issue as soon as they close a PR... Please just give us the option to turn off the automatic closing! |
Beta Was this translation helpful? Give feedback.
-
|
Technically no response from GitHub is a kind of response. |
Beta Was this translation helpful? Give feedback.
-
|
In which world? |
Beta Was this translation helpful? Give feedback.
-
|
It's a quiet no. On the upside: I heard rumours that GitHub is working on making triggers programmable with something like GitHub actions. If that is true then checkboxes become irrelevant because we can program up whatever behaviour we want. |
Beta Was this translation helpful? Give feedback.
-
|
If it is something like that, it would be nice if GitHub were to say so. |
Beta Was this translation helpful? Give feedback.
-
|
One more use case, when merging a PR shouldn't close the issue. To resolve some issues, from time to time I need more than one PR (usually in different repositories). So it's "slightly" inconvenient to reopen the issue each time a linked PR is merged. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to this feature request |
Beta Was this translation helpful? Give feedback.
-
|
My use-case is that we have a While I could avoid linking them, often the developers include screenshots and context in the PR that is not in the original issue, and it's nice to be able to allow testers to see that context for their testing. |
Beta Was this translation helpful? Give feedback.
-
|
The behavior seems to have recently worsened. I am getting issues closed even if I don't link them to the PR, just because my commit format includes the issue identifier to trace the commits in the main branch after merge and squash. |
Beta Was this translation helpful? Give feedback.
-
|
I also recently experienced this. In my case, explicitly writing "Does not close ..." still led to auto-close of the referenced issue. |
Beta Was this translation helpful? Give feedback.
-
"Close" is a keyword hahahahaha |
Beta Was this translation helpful? Give feedback.
-
|
I guess it was worth a try :) |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, this would be great. We have fairly large user stories which require multiple PRs, and having them be linked but not closed would be awesome. Also having a magic word would require less manual work which might be missed. |
Beta Was this translation helpful? Give feedback.
-
|
We have a Quality Assurance (QA) team that reports bugs via issues on GitHub projects. Whenever a bug is identified, the QA team creates an issue and the developers later link the issue with their relevant Pull Requests (PRs). After the PRs are merged, the issue is closed. However, the QA team still needs to retest the solution. In this scenario, we would like to configure the issues to remain open even after the linked PRs are merged. This would enable the QA team to retest the solution with ease. Thank you in advance! |
Beta Was this translation helpful? Give feedback.
-
|
@mstojanovic8 agree, we I need this as well! |
Beta Was this translation helpful? Give feedback.
-
|
I don't see anyone highlighting the need for creating this change also for Github Enterprise Server, so I'll add that from me :) |
Beta Was this translation helpful? Give feedback.
-
|
I thought that all changes which made it into the public version of Github then were pushed into the next release of Github Enterprise? But in general, it's true, this restriction is even more surprising given that there are paying customers who are forced to workaround GH's ideas around process, that issues should be automatically closed when a PR is merged... |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to getting this addressed in a better, more elegant way. |
Beta Was this translation helpful? Give feedback.
-
|
+1 It's like a car with an automatic parking feature. Convenient for fitting into easy spots without effort, but in some situations, you might prefer to control the parking manually to ensure it's done according to specific needs or constraints. Please make this an option, I dont really care what the default is as long as I can change it. |
Beta Was this translation helpful? Give feedback.
-
|
Also note that the keyword recognition is somewhat dumb and can be triggered accidentally. For example this trivial NFC commit closed an issue because I accidentally used the word "fix". Moreover, the after I reopened it the PR was closed again when the same commit was pushed to a private copy of the repository. This is outright buggy behavior in my opinion... |
Beta Was this translation helpful? Give feedback.
-
|
Please make this an option to auto-close an issue when a PR is merged. +1 to a previous post on making auto-close off by default and providing the option to auto-close when a developer links the PR to the issue. |
Beta Was this translation helpful? Give feedback.
-
|
+1 make auto-close configurable. That's annoying, I want to have my Project item to move the testing when my PR is merged... not close that issue :( |
Beta Was this translation helpful? Give feedback.
-
|
+1 Agree with everyone here, it is maddening! |
Beta Was this translation helpful? Give feedback.
-
|
Please fix this |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Does anyone posting +1 spam really think that someone@github.com is:
Breaking news: no. The only effect of +1 spam is to spam people also annoyed by this bug. The only thing that has a (very remote) chance of making some difference is to add a "thumb up" at the top. Or write github.com a big check, and then ask your github.com contact directly. If your company does write GitHub a big check then go and try to leverage that. |
Beta Was this translation helpful? Give feedback.
-
|
Another option: Open a support ticket. I'm in contact with GH support regarding runners not reliably picking up jobs and we briefly discussed this issue here. They are aware, but need to feel the urge. Just open tickets for broken PR workflows till they give up. No one from GH is monitoring this discussion. And given the amount of clueless "+1" spammers, i can't really blame them. |
Beta Was this translation helpful? Give feedback.
-
|
Some hope in https://github.com/orgs/community/discussions/17308#discussioncomment-11567231 (this issue is scattered across too many duplicates) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for passing that along. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Just today I created a pull-request and mentioned an issue there. I didn't even used the I later added the same issue through the sidebar. This method also closes the issue... This is stupid. Please, fix this. |
Beta Was this translation helpful? Give feedback.
-
|
It turned out that the first line shows that the pull request will close the issue because of the second line. |
Beta Was this translation helpful? Give feedback.
-
|
+1, especially with the tasklist's sunset. If we have to manage PR's using a markdown table, I might wonder why this tool is so popular 😅. The GitLab's solution is the best alternative. You can link issue & [P|M]R and only |
Beta Was this translation helpful? Give feedback.
-
"Success breeds complacency" |
Beta Was this translation helpful? Give feedback.
-
|
We're using Github Enterprise and have the same issue. Even though our linked Projects have the Workflows turned off, it is incredibly frustrating that we have to manually re-open issues after every merge. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, issues are not billed as a separate line item, and you cannot reduce the revenue GitHub receives from your subscription by disabling issues. So the idea that you can "speak with your money", when the system is designed specifically to avoid that, is not an effective one. |
Beta Was this translation helpful? Give feedback.
-
|
@sudoforge, you can just cancel the subscription. |
Beta Was this translation helpful? Give feedback.
-
|
I'm well aware. What the person I responded to had stated is that they moved to Jira and use GitHub only as a repository and CI tool. My comment here was pointing out the fallacy with the idea that doing that resulted in a revenue loss, as the user claimed. |
Beta Was this translation helpful? Give feedback.
-
|
Anyway, this is implemented: https://github.blog/changelog/2025-04-23-users-can-now-choose-whether-merging-linked-pull-requests-automatically-closes-the-issue/ |
Beta Was this translation helpful? Give feedback.
-
|
In my experience most teams do prefer using a dedicated project management tool like Jira or Asana, and the developers only use GitHub for code respiratory management, not for project management. GitHub has a long way to catch up with the dedicated tools. |
Beta Was this translation helpful? Give feedback.
-
|
Would be great to have this. Just linking a PR withour closing the issue seems to be a standard feature. |
Beta Was this translation helpful? Give feedback.
-
|
Adding my voice of support to this request. It makes linking PRs for us very problematic and removes all benefits from doing so. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that this issue is finally moving forward. See https://github.com/orgs/community/discussions/17308#discussioncomment-12504704 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
great news |
Beta Was this translation helpful? Give feedback.
-
|
Well, it's not really here nor is that a bug fix. They just added an option to completely disable the feature. If it's enabled, it's still broken as before. "We can't fix it. But see, there's now a switch to remove the broken feature that our competitors have successfully added years ago. Aren't we great? Enjoy". I'll try that strategy with our customers and see how it ends up. I'll maybe report back if I don't get fired. |
Beta Was this translation helpful? Give feedback.
-
For me, this works. |
Beta Was this translation helpful? Give feedback.
-
|
@epasveer And that's perfectly fine. Still it's not fixed and there are paying customers like us who have payed for "it works", not for "if it doesn't work, we'll just remove it". It's like having a flat tire and then just throw it away, have everyone in the cart lean to the other side, and hope that ground contact will be minimal. |
Beta Was this translation helpful? Give feedback.
-
|
Understood. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Context
This issue serves as an urgent follow-up to the discussion initiated here: GitHub Community Discussion #23476. Despite considerable community support, there has been no official response for three years. The lack of attention may be attributed to the discussion being marked as answered by @AndreaGriffiths11.
Current Behaviour
Rationale for Reconsideration
The current behaviour is incongruent with the workflows of numerous development teams for several reasons:
Inadequacy of Suggested Workarounds
Previous discussions proposed linking the PR to the issue without using specific linking keywords. This approach, however, fails to display the PR in a GitHub Project card, negating the benefits of linking.
Proposed Alternatives
The issue can be addressed through multiple avenues:
Community Sentiment
The following comments and discussions underscore the urgency and support for revisiting this issue:
We urge the GitHub team to address this issue promptly to align the platform's functionality with the diverse needs of the development community.
Disclaimer: Yes, ChatGPT wrote this.
Beta Was this translation helpful? Give feedback.
All reactions