Closing a PR should not close linked issues #66741
Replies: 33 comments 28 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.
-
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.
-
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.
-
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.
-
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.
-
I've stopped linking my issues unless I really want the current behavior (which is almost never). What I think Github devs could do, which may be a more in the "low hanging fruit" category, is to summarize (on the right) which pull-requests have cited this issue (and vice-versa: which issues a pull request cites). Wouldn't address all use-cases, but it would help testers easily access the context they need from those other issues/PRs rather than searching through the conversation history. |
Beta Was this translation helpful? Give feedback.
-
We have now sort of solved this problem by just not using GitHub issues / projects anymore but moved to Jira. Much better experience overall and not looking back. And a great GitHub integration in Jira including PRs, commits, build status, and deployments. Notice the closed/merged PR but the issue is still "In Progress". Can be that easy. Not really an option for open source projects, but if you have private repos, give it a try. Maybe this is just GitHub realizing that company customers will at some point use Jira anyway and oss projects don't really have a choice - so they're just ignoring the problem because there's nothing to win, even if they fix it. I mean, 4 years later and not even a switch to disable the default action. It can't be that difficult. |
Beta Was this translation helpful? Give feedback.
-
@lidiaparrilla another option for solving this: A new set of linking keywords that aren't associated with auto-close, such as: |
Beta Was this translation helpful? Give feedback.
-
Shocking this is still an outstanding ask considering Microsoft is putting more effort and investment into GitHub than they are Azure DevOps (ADO). If they expect enterprises to adopt GitHub in place of ADO for work item tracking, not just for the repository features, they need to step up on Project. Issue and PR features, particularly this one. An "Issue" should rarely ever close simply because a PR was completed. In a "GitHub Flow" approach with "trunk" development and Kanban for quick shipping, it's understandable why GitHub is fully content with the way their Issue-closing PR keyword functionality works, but not for most enterprises. @AndreaGriffiths11 |
Beta Was this translation helpful? Give feedback.
-
+1 - please do it ASAP, it is really painful to re-open everything and restore issues in the projects |
Beta Was this translation helpful? Give feedback.
-
Can anybody suggest an alternative to github, please? It is laughable that software designers would make such a flawed basic assumption that I want to close an issue when I merge a PR. |
Beta Was this translation helpful? Give feedback.
-
My team also needs this resolved. |
Beta Was this translation helpful? Give feedback.
-
Why isn't this "feature" just an Action? They could add it as a default if they have this as a strong opinion. |
Beta Was this translation helpful? Give feedback.
-
Wouldn't making the keywords "fixes", "closes", ... actually work like they imply solve the problem? If you want a PR to fix an issue, you put "fixes #.." in the PR description. Simple, but that's NOT what GitHub does. Any reference at all "may" close the issue, whether any keywords are present or not. IMHO, that's the bug. If I don't tell you to close it, then don't close it. It would also be nice if it did create the link when an issue mentions a PR (but not close it unless a keyword says to). I use "Ref #..." all the time. This is annoying on a solo project, but I'd imagine it's downright maddening on a large one. And clearly it is if this one bug is causing entire organizations to use something else. That's a lot of time and effort to work around something GitHub doesn't even consider worthy of notice. GitHub, listen to your customers! You're losing them over this!! |
Beta Was this translation helpful? Give feedback.
-
Please fix this so we can maintain some coherence between multiple related conversations without auto-losing the need to address related matters outside of a PR. |
Beta Was this translation helpful? Give feedback.
-
Yep, I still need this. I posted on Jan 11, 2024, and it appears it still is not fixed! |
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.
-
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