I think the answer is no, but maybe I'm missing something: in most repos, you only have one or two admins, and a bunch of "collaborators". But it looks like the collaborators can't assign issues (eg, to themselves), nor can they label issues (even ones they created).
Bug? Design feature? I'm using it wrong? Are there any workarounds?
Looking at Issues 2.0: The Next Generation, this seems to be by design, and from the comments, this isn't the only "problem" users are facing:
It looks like issues can only be assigned to collaborators.
I'd still like to be able to assign an issue (or someone to claim one) to a developer who is not a repo collaborator. After all it is a very common workflow that collaboration happens with forks and pull requests.
One potential workaround (not tested myself) is for a user to fork the original repo, and reproduce the issue in the issue tracker of that new forked repo (that he owns):
the new issue would keep an html link to the original issue of the original repo
the user can assign and label issues.
Obviously that involves a bit of duplication, but for bugs a user wants complete ownership of, that can be worth doing.
Related
I am trying to learn about git/GitHub workflow. I'm on branches, and learning about the different typical branch name prefixes. I've read several of the key articles.
If I name a branch issue-*, you can correspond that to an existing issue in the GitHub issue tracker by adding its number, like issue-32, is that right?
Is this number only for the developer's own tracking, or does it actually get associated with the issue, such that the branch somehow appears linked on the issue?
If a topic branch named like issue-32 does form an association with the issue, would other conceivable topic group prefixes do the same? Ie. If you were storing a feature note as issue 76, does branch feature-something-76 make any association with it?
Thinking it through, am I wrong to think that a branch could be associated with an issue? Is it, rather, that you associate commits with issues? And, if that's the case for issue-*, it's also the case for feature-*?
Ie. Should I only ever be referencing issue numbers in a commit message, eg. "Fixes issue #32" (and is there any particular nomenclature required beside use of the integer?)?
This answer shows GitHub, only a few weeks ago, introduced a new feature to create a new branch from an existing issue. But that's a) the other way around from my question and b) from the web (not sure how I'd do this in VS Code). Also seems like the linkage only happens upon a pull request.
On Github issues pages, how do you know which post contains the solution to the issue?
Take this page, for example.
The issue is closed, so we are to presume the problem is solved... yet this discussion thread (and many are much longer) seems to be mostly people talking back and forth in circles and it's very confusing to try to determine which post is intended or generally accepted to be the solution.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
Ideally, if a pull request fixes an issue they would be linked by referencing the issue from the PR. For example, if a PR closes issue #123 the PR description would say closes #123 or fixes #123. You can also link them manually.
The PR would appear in the issue's "Linked Pull Requests" sidebar, and vice-versa.
For example, we can see that this PR is linked to this issue.
And from the issue we can see the linked PR.
In the issue, we can see activity on the linked PR as well as anything which mentioned it. A mention is a commit log or comment or issue or PR with something like #43878.
If the issue is closed for some other reason, ideally the person closing mentions why in a comment.
If people keep coming back to the issue and are confused, that may indicate the issue is not closed, or perhaps there is a related documentation issue.
In your example, we can see where the issue was mentioned in other issues.
And, sure enough, its referenced in issue #63056 and in PR #9 https://github.com/aws-amplify/amplify-flutter/pull/9#issuecomment-670038832. That information might help.
And we can see why the issue was closed, the change was intentional.
Unfortunately, the reason and resolution is buried in a comment. Improving the documentation may have been a better choice. That would have been done in a linked PR.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
That would be nice. I don't believe Github has that feature. Posting it here is unlikely to reach Github. You could suggest it in Github Community or ask Support.
As a work around, one can make their final comment and then lock the issue so no further comments can be made. This would avoid burying the resolution. Then people would have to open a new issue if they really want to comment.
Or, one can edit the description of the issue to include a prominent reference to the resolution.
See also
Autolinked references and URLs
Linking a pull request to an issue
Is there any documentation out there to suggest that GitHub issues are eternal? More specifically, are their URIs reliable to link to?
E.g., I want to link to a Joda-Time issue in a Javadoc to give context as to why a custom de/serializer was necessary. If the link is reliably static I'll be comfortable referencing it in code.
Yes
Git issues are completly reliable, no one can remove an issue, even repository's administrators.
A git issue will never die, the worst thing that can happen to an issue is getting locked, resulting in others not being able to comment on them, but still, it's visible to everyone.
Edit: Please note that by removing a repository, all it's issues, pull requests, wiki pages, etc. are removed. More about forks on this.
Nearly every issue I file on gh refers to code on a particular branch. Does github have any mechanism to link an issue to the branch?
I need to filter issues by branch, so I am not distracted by issues in other feature branches.
Is there a way to do this? I know milestones can be (ab)used to reach a similar effect, but things get really confusing when the branch becomes a pull request and it shows up as another issue.
References
Often times issues are dependent on other issues, or at least relate to them and you’d like to connect the two. You can reference issues by typing in a hashtag plus the issue number.
Hey #kneath, I think the problem started in #42
Issue in another repository? Just include the repository before the name like kneath/example-project#42.
One of the more interesting ways to use GitHub Issues is to reference issues directly from commits. Include the issue number inside of the commit message.
By prefacing your commits with “Fixes”, “Fixed”, “Fix”, “Closes”, “Closed”, or “Close” when the commit is merged into master, it will also automatically close the issue.
References make it possible to deeply connect the work being done with the bug being tracked, and are a great way to add visibility into the history of your project.
Since March 2022, you can:
Create a branch for an issue
You can now create a branch directly from an issue to begin development work that's correlated to that issue.
Branches connected to an issue are shown under the "Development" section, which has replaced "Linked pull requests", in the sidebar of an issue.
When you create a pull request for one of these branches, it is automatically linked to the issue.
For more information, see the documentation.
Here is an animated image showing how a branch is created for an issue.
After creation, the linked branch is shown in the Development section:
The OP asked:
I need to filter issues by branch, so I am not distracted by issues in other feature branches.
It is still in public beta, but the new Development section can help you list branches associated to issues:
So for any issue you need to work on, create a new branch:
Use labels to organize issues. They aren't inherently branch-specific, but you could make a tag for each branch if that is how you want them organized.
When you have admin access to the repository, there should be a button called 'manage labels' on the issue page. That will let you add, modify, or delete labels. You can apply labels to issues a few different ways. One way is to open the issue and click the labels button just to the right of the main body of text for the issue. Once you have created a label, it will appear on the left just above the manage labels button. You can click on each label to view all the issues that have been marked with that label.
Is it possible to completely remove an issue from the GitHub issue tracker?
No, the github API only allows you to open/close/reopen issues. Here's the Issues API docs.
You can edit an existing issue (let's say if it's a duplicate) and you can change the title, description and target milestone to be something completely different. That's as close as you can get to removing the ticket, AFIK.
Update Nov 2018: You now can delete issues if you are a owner of the repository!
See "Github - remove issues entered in error"
https://docs.github.com/en/github/managing-your-work-on-github/deleting-an-issue mentions:
People with admin permissions in a repository can permanently delete an issue from a repository.
For other people (without permission), questionto42's comment shows that you can ask to GitHub support for the issue to be deleted, as illustrated here.
At May 2018, original answer:
Three 8 years later, and closing issues remains the answer (still no deletion possible).
See "The Ghost of Issues Past", where GitHub advise to check and close:
issues opened over a year ago state:open created:<2013-01-01
the ones I'm involved with involves:twp state:open created:<2013-01-01
and those not updated in the last year involves:twp state:open updated:<2013-01-01
For posterity: Deleting issues would be a bad thing, since in general they can be targets of associations on github.
But if you are willing to sacrifice the collaboration info, here is a "whack it with a sledgehammer" approach:
Clone your original repo.
Copy your issues via the Issues API.
Delete the original repo; alternatively, chose a new name for your new repo.
Re-create a new repo based on your clone.
Re-create the issues you want to keep via the Issues API.
I imagine this could potentially lose a lot of other linking information as well such as forks, pull requests, etc.
Public feature request
I wrote to GitHub in 2014-08 and https://github.com/jdennes replied by email:
Thanks for the suggestion. It's only possible to edit/clear the issue content currently. However I've added a +1 to this suggestion on our internal Feature Request List.
confirming it was not possible.
Best workaround so far
set the title to something that will never conflict with any search, e.g. a single dot ..
This may not hide the history of your blunder entirely because of the automatic undeletable "changed the title to" comments.
make the body empty
GitHub staff has the power
If something is a security issue, contact GitHub staff, they usually reply quickly, and are able to remove issues for good as can be seen at: http://archive.is/OfjVt which has issue 1 and 3 but no 2.
You can delete the entire repo if it's really important.
Possible workaround
As of 04/2019 not all issues can be deleted current work around is to edit the issue then delete the edit history, the only downside is that the issue still exist and the old title could be seen.
You could by just asking to github to ban the user that created the issue 😁
Source: https://github.com/isaacs/github/issues/253#issuecomment-290944938
Users are unable to do this, including repository owner.
But issues can be deleted by Github support. One may contact them and request deletion. It may be delayed or refused but it is an available option that can be used.
Still impossible. Another workaround to the ones suggested in the other answers is to label the issue as "deleted" (or any other label you might fancy better), to be able to filter them out if you use the github API to retrieve them. Obviously you should use that specific label only for this purpose, setting the label when you close the issue.
You can create a new repository.
Transfer (yeah it is possible) unwanted issues to the new repository.
Then delete the new repository.