Our organization’s repo has a PR from a forked repo. In that PR, commits like “yaddayadda, fixes #123” are pushed. Github now references our issue 123 in the commit, even though the committer meant to close an issue created in their fork. Who needs to fix this? Is this something that I can prevent as a repo owner accepting PRs or is this something on their end? If it makes any difference, their repo is not publicly visible, while ours is.
In forks Issues are disabled by default because the idea is that people working in forks are generally working off of the parent repo’s issue list. So in the normal case, the #xx just works. If they manually enabled Issues on their fork, track them separately from the parent repository, but still merge back to the parent, they might want to use a fully-qualified issue link like
foo/bar#123 or just the full URL such as
[https://github.com/foo/bar/issues/123](https://github.com/foo/bar/issues/123). The closing magic will still work, even though their repo is not publicly visible.
As far as what you can do as a repo owner when someone puts an invalid “fixes #xxx” in their commit message, you have a few options:
- If they have left “Allow edits from maintainers” enabled (it is enabled by default), then you can interactively rebase the branch, edit the commit message, and force-push the change
- You can request that they do the work of changing their commit message and update the PR
- You can merge the PR and manually reopen the referenced issue
If they put it in the body of the PR, then you can always edit it out before merging the PR.
I hope that helps! Let us know if you have any other questions.
Thanks for your answer. I think I now understand what happens. Is there any way we could get a warning in a PR when the origin and target repos both have issues enabled and the
#123 might reference different issues depending on context?
I’ll pass along the feedback. I can’t promise when or even if it will be implemented, but I’ll let the appropriate team know.
supporting for my account