I've been trying to work with github-linguist for a while and it still gives a bit of problem.
After a few days of trying to figure out different issues with the language statistics, I managed to set .githubattributes with the right commands to get the correct statistics from github-linguist command:
But in GitHub's webpage/server it's still not showing up:
This is the link to the repo I am working on: https://github.com/FeriBolour/cotton-phenotyping
I tried different solutions:
Waited almost a week.
Pushed meaningless stuff to the repo to update the server.
It's still not working. What do you suggest me to do.
It could be two things:
It's not computing statistics on the branch you expect. GitHub only displays statistics for the default branch, but I believe locally you can compute statistics for any branch.
There's a bug on GitHub's side that caused the statistics update to be cancelled. I've seen that happen before while working on Linguist. I suspect it happens when the statistic-update job queue grows too large and jobs are dropped.
In your case, it's not problem 1 because you appear to have only one branch on this repository. It's most likely problem 2. You can contact GitHub support and they should have a way to manually trigger a statistic update for your repository.
I have this issue when I try to merge my branch to the main one for my RASA chatbot project and I want to know if there are any ways to fix this and create a pull request or should I just change my main branch to the domain-side branch
Ok so I fixed the issue by deleting the .rasa cache folder
This can occur when there are a lot of commits in your Pull Request
Unfortunately, this is a known github issue.
Thanks for writing to GitHub support and sorry for the trouble!
We have received a few similar reports regarding big pull requests. I can confirm that our team is working on fixing this problem, and I've added your report to that issue.
Unfortunately I won't be able to provide an estimated time on when this might get fixed. We know this is not ideal, but hope you understand.
Is there anything we can do to preserve our comments and alleviate this issue now and in the future?
You should be able to use our API to get a copy of the comments in this pull request:
https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
https://developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request
If you have any question regarding using API we can definitely offer more detailed instructions.
Unfortunately I'm not sure if there's anything you can do on your part to view this pull request normally.
One thing you could try is viewing this PR in Incognito window or logged out.
I was actually able to view the PR you linked because I don't have write access to this repository, so GitHub will try to load less things for me such as edit buttons and so on. Of course this won't allow you to merge the pull request and so on, but perhaps it would help for you to look at its content?
Lastly, while we are working on consistently supporting large pull requests, you might consider keeping pull requests relatively short for now to avoid running into this again.
I hope this helps clear things up, and please let us know if you have any other questions.
Please refer to the full discussion provided here.
We use VSTS/Azure DevOps at work, and have recently updated all our README's and wiki's in our company to improve life for new starters and team switchers, and for general quality of life.
I've just noticed that the [[_TOC_]] table of contents element is suddenly very janky - only a few links work, whereas it linked beautifully a few weeks ago. IT still creates the table, but the table is pretty useless if only 10% of the items actually go to the expected view when you click on them.
Does anyone know what caused this, and if there's a fix? Should I raise a bug with Azure?
Thanks!
A year ago I have started an issue on github repository of a popular open source project. There wasn't enough data to fix it because bug was caused only by one closed source program. Recently I have stumbled upon other program that causes the bug and this one is open source. This should make it possible to fix the issue.
I have added new comment in issue providing new information, but it got no response for 10 days.
https://github.com/linuxmint/Cinnamon/issues/6253
I wonder if maintainers see comments on old issues in their notifications?
If they do did they discard it by accident or perhaps because in their experience most comments on old issues are useless?
Should I just edit last comment there slightly?
Will they see that?
Or what to do?
The good news is the project is not dead. Issues have been closed recently and PRs have been merged. Someone is watching the queue. The bad news is the project has over 800 open issues at this time which means they're probably swamped.
Open Source projects are typically run by volunteers, and that looks like a low priority issue. If you want it solved, do everything you can do reduce the work necessary to fix the problem. You've already given clear instructions on how to reproduce the problem, that's a very good start.
The single best thing you can do is submit a PR with a complete patch including tests. Be sure to conform to their developer guidelines. That project does not leave PRs open long. If you can't do a complete patch, take a stab at it and submit the PR asking for help. If you don't know where to start patching, make a comment on the issue asking for help with where to start.
Basically, do the work. If you can't do the work, show a willingness to do the work.
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.