Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
GitHub Community
Prevent issues from being closed by merging linked PRs #17308
Replies: 40 comments 53 replies
-
|
Assuming an issue is automatically fixed because a single merged PR mentions it seems very naive - and indeed dangerous. Validation does not stop after merging. A simple workaround is to avoid the "magic words / syntax", for instance this should avoid the problem: cc: @defunkt (https://github.blog/2013-01-22-closing-issues-via-commit-messages/) |
Beta Was this translation helpful? Give feedback.
-
|
Where is that? I can’t find how to get there on either my company’s github account or my personal one so am missing something. |
Beta Was this translation helpful? Give feedback.
-
It will not help you to solve this problem, but these are workflows that live inside projects. You can find it in http://github.com/orgs/{orgName}/projects/ |
Beta Was this translation helpful? Give feedback.
-
The issue is not on |
Beta Was this translation helpful? Give feedback.
-
that configuration is on |
Beta Was this translation helpful? Give feedback.
-
Correct 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see 'disable auto-close' configurable for the repo and/or 'disable auto-close for different repos'. I encountered this issue because I'm working around a limitation in dependabot where dependabot only scans the default branch. I have a project where two branches are supported, but code has diverged. Eg, This all worked fine until today where I noticed that someone used Having more flexibility with dependabot (eg, allow selecting multiple branches, not just the default one) would address this for the above use case, but I'm mentioning it because it seems like cherrypicking and forks could be affected in the general case. |
Beta Was this translation helpful? Give feedback.
-
|
This re-opened issue was automatically re-closed... by a fork!! This feature is train wreck, it's basically an advertisement for JIRA. There should at the very least be a way to turn it off. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see this as well. I often use |
Beta Was this translation helpful? Give feedback.
-
|
This should be treated on high priority. It breaks lot of workflows and not using magic keywords prevents issue from showing up in tracker. One should be able to switch off auto closing of the issue. I guess every large organisation has a QA team that verifies the issue and then closes it (even after merging pull request, regression test has to be executed) |
Beta Was this translation helpful? Give feedback.
-
|
+1. Sometimes I will have a meta-ticket requiring changes in multiple repos and it is frustrating not being able to use the typical workflow of linking the pull requests to issues. I think that a good way to improve this behaviour would be to require all of the linked pull requests must be merged for the issue to be resolved. |
Beta Was this translation helpful? Give feedback.
-
|
I consider this to be a bug just as much as a feature request. On an issue page in the meta data section it says:
And in the pull request it says:
The operative word there is "may", which certainly does not mean it should automatically close it by default. |
Beta Was this translation helpful? Give feedback.
-
I agree with this. While I understand why it says may it seems to indicate that there is a way to configure this behaviour. Unfortunately it seems there is no way to do this. |
Beta Was this translation helpful? Give feedback.
-
|
The model Github is perplexingly enforcing does not fit well with trunk based development. I hope they take another look and make it happen. |
Beta Was this translation helpful? Give feedback.
-
|
Having multiple PRs and closing one does not mean issue can be closed. |
Beta Was this translation helpful? Give feedback.
-
|
yes. I totally agree, there are different issue and different project is different. Feel like there should be a way to have settings for this |
Beta Was this translation helpful? Give feedback.
-
|
It would be very helpful for us as well. We have projects that span two or three repositories and often need to make changes to all of them in order to implement a feature. More granular control over the interaction between pull requests and issues would really help clean up the workflow and make sure things don't fall through the cracks |
Beta Was this translation helpful? Give feedback.
-
|
GitHub devs, if the magic word stuff etc, is too complex, maybe just a repository level setting "Disable auto-close issues" , which can be Then wherever the logic runs post merging a PR, just also have a boolean check for this repository property, surely it can't be too hard? |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see that option too Another option is don't automatically close the issue if the target branch is not |
Beta Was this translation helpful? Give feedback.
-
|
At this point, the workarounds are either to unlink the issues, merge the PR and link the issues again, or to re-open the issues after merging PR. The first one is preferred, as the second one may trigger some workflows. But the first one is not easy if the linking was done using commit messages unless you amend the messages and force-push the amends. It's easier if the linking was done via PR description or manual selection in the sidebar. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the current functionality is tragic. We have to reopen every issue and move it back out of done in its related project after the pull request is merged. |
Beta Was this translation helpful? Give feedback.
-
|
I'm inclined to consider this a bug. I can't understand why allow linking multiple PRs to an issue if only one is needed to close it. Having the possibility to configure this behaviour at the repository level makes perfect sense to me. |
Beta Was this translation helpful? Give feedback.
-
|
Kind of related but I maintain a project that is a downstream fork of another one. I just realized that one of my issues was closed because the upstream fork commit used magic word to close an issue and unfortunately that number matched an unrelated open issue in my repo and closed it as well. This automatic non-configurable setting virtually makes a downstream fork's life difficult because now I'm paranoid how many times that has happened and whether I need to scrub the commit messages every time I merge form upstream. |
Beta Was this translation helpful? Give feedback.
-
|
If you scrub the commit message it will alter the SHA, making your fork look different from the upstream despite having all the same code. You can reopen the issue. It shouldn't get closed again by the same commit. Interesting report of a strange behavior though. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's what I meant. Probably bad choice of words there. But no I definitely do not want to alter the commit hashes, so yeah I will just have to scan for issues. I'm still debating whether I should just sort issues by most recently updated after a merge and just see if I have any "updated within last 5 minutes" issues and go re-open them as a quick hack. I don't want to |
Beta Was this translation helpful? Give feedback.
-
|
Yes you can sort issues by "Recently updated" in the Closed list and that should show what was closed recently. You can bookmark the filtered page for quick access. Too bad you can't save the sorting option as default yet. (#16154) Is your repo public? I'm curious how this ends up being a big problem for you. Most forks don't track issues of their own. |
Beta Was this translation helpful? Give feedback.
-
Sure, it's this one: https://github.com/macvim-dev/macvim It adds unique functionality on top of base fork, and therefore exists as its own entity (it's not a GitHub fork so you won't see the officially stamped "forked" entity, but more that the project itself is split from the upstream project). FWIW for the most part this is not a huge issue because the numbers do not line up usually. |
Beta Was this translation helpful? Give feedback.
-
|
Oh cool. Nice tool you have there. The readme is a bit lacking though, as I couldn't know at a glance what the unique functionality is over regular Vim. BTW if you want to quickly check the new commit messages from the upstream before merging, you can try this (and probably automate with a script): # create a temporary branch
git checkout -b fastSquash master
# squash merge the upstream
git merge --squash vim/master
# just add all the merge conflicts. (we're going to throw away this anyway.)
git add --all
# see all the commit messages - make note of any issue mentions.
# close when done and allow the commit. (we're going to throw away this anyway.)
git commit
# return to previous branch and delete the temp branch.
git checkout -
git branch -D fastSquash
# continue with your usual merge. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like it if there could simply be another "magic word" which links the issue but avoids closing it upon merging. I want the choice to make some issues still close it with "closes" but others (which might require several PRs before the issue is fully completed) only link it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm very surprised that this still isn't configurable! |
Beta Was this translation helpful? Give feedback.
-
|
It makes me think that Github is not very serious about their |
Beta Was this translation helpful? Give feedback.
-
|
Please make it configurable. im just reopening the issue over and over |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Use the buttons at the top. If you have no comment to add, then don't add a comment. Stop spamming. |
Beta Was this translation helpful? Give feedback.
-
|
Can you make this configurable pls. |
Beta Was this translation helpful? Give feedback.
-
|
It would be great to have cleverer keywords. So instead of all the keywords (e.g. e.g. |
Beta Was this translation helpful? Give feedback.
-
|
I'm certainly not opposed to more keywords, but in my mind it doesn't solve the real problem, which is that I should be able to say not to auto-close issues. |
Beta Was this translation helpful? Give feedback.
-
|
+1 We've been waiting for this for more than 4 years. Still not resolved. 🔥 |
Beta Was this translation helpful? Give feedback.
-
|
Do you have a workaround for keeping issues alive after merging linked PRs? |
Beta Was this translation helpful? Give feedback.
-
|
I want a simpler solution -- please remove this auto-close feature entirely. Assuming intent with very common English words that people would use in a good PR description is, well, assumption. And assuming things is never a very good idea. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not entirely sure whether it was brought here as well, but github will close issues cross different organizations if the user who merged the PR has maintainer access in both. This is completely unexpected, because the repositories are not even under the same org. An example where it happened. A simple toggle to not auto-close when the repo where PR was merged is not the same where the issue is could be really great addition and probably be really simple given that the URL and the check is likely nearly at the same place, given that it uses org settings when doing so, because when I wasn't an org maintainer it was not doing so IIRC. Right now it took me 10 minutes to figure out what happened, since I clearly remembered that the issue was opened. |
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.
-
|
I'm having the problem that the issues are being closed when I do a commit with fix tag, but, this did't happened two weeks ago |
Beta Was this translation helpful? Give feedback.
-
|
I just found out that if you link the issue in PR comment it won't close. Only tagging it in PR title closes the issue. |
Beta Was this translation helpful? Give feedback.
-
|
If you use one of the keywords like Fixes or Resolves, I think it will close, even if it's in a comment. Or maybe only in PR description (the first comment). Example: |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm that will be closed. |
Beta Was this translation helpful? Give feedback.
and others
-
Manually copied over from https://github.community/t/feature-request-prevent-issues-from-being-closed-by-merging-linked-prs/3255 (where https://github.com/akshaymankar was the original requester).
Beta Was this translation helpful? Give feedback.
All reactions