Closing a PR should not close linked issues #66741
Replies: 40 comments 34 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.
-
|
In your opinion, if GitHub allows triggers to be programmable through GitHub Actions, would that address the issue of automatic closing of linked issues? |
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.
-
|
What |
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.
-
|
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.
-
|
There is gitlab.com. Not sure if it has the same problem. Likely not. |
Beta Was this translation helpful? Give feedback.
-
|
We're using Github for the repos and actions only. Issues live in Jira with a great integration (made by Atlassian, see my comment further up). As a former Gitlab Ultimate customer, i can't recommend GitLab as a replacement for GitHub either. While you won't have the issue from this discussion when using GL, its planing features are still years behind of what you can do with Jira. And GL, while promising being an integrated tool for everything, is in fact only mediocre in most of its features (with the exceptions of the runners, GL's version of actions, they are amazing) and for that really overpriced. What i don't get is GH not reacting at all. A usable issues feature with working links between PR and issues would have been a reason for us to upgrade to Enterprise and not even think about Jira. Now it's only Team and the bigger cut goes to Atlassian. And, for the downvoting GH fanboy: Just suck it up. If you are happy with what's available for free, good for you and feel free to keep using it. Or just add some insights for why you downvoted (you know it's not anonymous, right?) so we can discuss alternatives and understand your reasoning. For most participants of this discussion the feature is broken and they are not interested in a cult dispute but in a solution. |
Beta Was this translation helpful? Give feedback.
-
|
It doesn’t need to be anonymous. Does it? Just looking for more than +1s or “me toos”. Figured that was obvious. Also there’s plenty of suggestions earlier in the thread, if there was something new that had come to me (or others) we likely would have mentioned it. 🤷♂️ Edit: In case I haven't been clear, I don't disagree they should improve the functionality. They 💯% should. |
Beta Was this translation helpful? Give feedback.
-
|
I wondered why some platforms started removing "thumbs down" a while back and observed with a lot of interest. It makes a lot of sense to me now: if you don't like something, then make the effort to explain why. Maybe propose some alternative even. It does not have to be long at all but you should say "something". Then your comment/alternative can be upvoted by people agree with you, possibly upvoted more than what you disagreed with. Downvoting and saying just "no" without any message is confusing, purely aggressive and never adds any value. It's not like there is a shortage of things to ignore and like we need any help highlighting the "least interesting things on the Internet". A lack of thumbs up is perfectly enough for that. Real votes in "real life" are similar: no "thumbs down" there either. It's OK to hate some candidates, but you need someone to do the job at the end of the day. So you must pick some alternative candidates. Not voting at all is also an option. Voting "against" some people specifically would make no sense and does not exist. EDIT: A "report" button is needed. That's a different issue. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, this thread is 🔥 😂 |
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.
-
|
At this point, I'd welcome anything to turn the "feature" off. |
Beta Was this translation helpful? Give feedback.
-
|
Well if you want a workflow you can use it either way |
Beta Was this translation helpful? Give feedback.
-
|
Yes, yes, making users work around design flaws is the future of software! /s |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't saying it was a "good" solution, but if @AndyPook is happy building it one way then obviously others could build it the opposite way 🤷♂️ |
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.
-
|
Today, I encountered the problem where I thought that me, referencing the issue in the PR without any keyword, made GitHub decide to close the issue after PR merge. But it turned not to be the case. I left a comment with the details below: https://github.com/orgs/community/discussions/66741#discussioncomment-11956270. But now I'm interested: can you show an example of GitHub closing an issue, when the corresponding PR doesn't have words like "resolves" or "fixes"? |
Beta Was this translation helpful? Give feedback.
-
|
It's been a while, but IIRC, the bug happens only if you haven't enabled Projects for your repo? It might have been some other GitHub feature that needed to be enabled, but I'm now using it whatever it is. |
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Does anyone posting +1 spam really think that [email protected] 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.
-
|
(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.
-
|
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.
-
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