Github outdated diff functionality - github

Did the "outdated diff functionality" get removed or are we just using comments wrong now?
Whenever a updated a review comment I no longer get the "outdated diff functionality". This makes it extremely hard to keep track of what was updated when working with a team.
Cheers.
Edit
Received an e-mail from github that explained the functionality is no longer active and that they are working on bringing it back again.

Received an e-mail from github that explained the functionality is no longer active and that they are working on bringing it back again.
It has been restored.

Related

Github pull request issue "This comparison is taking too long to generate" with project using RASA framework

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.

GitHub pull request reviews line comments behaviour

Recently GitHub introduced some new features including Pull Request Reviews.
In the past, line comments in Pull Requests would collapse like this after the line was changed in further commits:
Since the launch of the new feature, line comments no longer collapse even after further commits that address the issues. So far I've only had one PR and I'm not sure if the reviewer added single comments or used the new "Start a review" feature.
How can I get the old behaviour back or does it improve in the new "Start a review" feature?
I've watched their video tutorial on this feature and I can't determine whether the behaviour right now is what I'm supposed to be experiencing.
I sent a message to GitHub support and received the following response:
Sorry for the trouble! We are aware that with reviews comments no longer become "outdated" after new code is pushed.
This is definitely on our radar as something we need to address. I can't give a timeline for it, but we will be looking into it soon.
Since two years ago, GitHub now (august 2018) proposes "Collapse all diffs in a pull request at once":
When a pull request contains a lot of changed files, code reviewers can find it hard to isolate the changes that are relevant to them.
Now you can collapse (or expand) the contents of all diffs in a pull request by holding down the alt key and clicking on the inverted caret icon in any file header.
You can then go one step further by using the “Jump to file or symbol” dropdown to jump to the file that you’re interested in and automatically expand it.
That is not exactly the old behavior, but that does still improve the code review process.

Can I change the state of Github Issue? Open > Needs Verification > Closed

It would be really great to have a Github issue be in an intermediary "Resolved" state before I close the issue.
Right now, I have a "Resolved" label and I manually select the issue and change it's label on the web after I commit. Is there a way I can do this from the commit message?
I am sure this is a common problem. How do you guys solve this?
I have never used Github API but can this be done using the API If I were to do this myself?
Since September 14, 2016 you could manage your states with projects. See image below:
Reference and source: GitHub - A whole new GitHub Universe: announcing new tools, forums, and features.
I know it's not like a new state like "needs verification" because you can't like #NevikRehnel said in his answer. But you could make a column named "open", "needs verification" and "closed" and all the issues can you list in correct column.
No, Github issues only support two states (open and closed). Any other "states" must be realized via labels, as you are already doing right now.
And as of right now, there is no way to apply labels from commit messages.
You can always request such features from Github support of course, and they might be implemented at some point.
You can manage this problem using this method : Adding and reassigning github issues via commit message.
A simple ruby script will run on each commit, and check the commit message looking for ~myLabel and =assignedMember to update correctly the issue.

How to view line comments in GitHub?

I spent all morning in GitHub reviewing a pull request, writing detailed comments on many lines in the Diff view on the pull-request page.
I individually saved every line-by-line comment, and they all appeared in their correct places. I left the pull-request page, and when I returned to it, all my line-by-line comments were gone!
I have no idea why they disappeared, where they went, whether other users can see them and I can't, what any of this means, and whether I can trust myself going forward using GitHub, or whether I just have to go back to the telephone and fax for remote collaboration!
I did some web searches such as "how to view line comments in GitHub" for info about this, but could not find anything to relieve my panic. I will be grateful for advice and clues.
This is top result for "Can't view github comments" in google.
If you're here because you've left comments, and can see your own comments, but others cannnot, then check for a yellow pending label on your comments. Others cannot see your comment until you've completed the review process and selected whether you want to request changes. Once you click through a full review, then others will see your comments.
Note: I'm answering a slightly different question than the O.P., but I have a feeling that lots of other devs with this issue are hitting this stackoverflow question. I'm just hoping to help them. I myself had this issue and couldn't find a more relevant answer than this thread. :)
The line-comments depend on the commit that were made on.
If the person that made the pull request rebased that commit then you're not looking at what you were previously looking. It's a different commit, thus there are no comments.
Look on the 'Your Actions' tab and find a line in the actions' history were you commented on that commit, click that commit and you'll see the comments are still there.
If the commit was rebased, you wont find that commit were it used to be (some branch) and not on any repo probably (if it's not on another branch). It is just cached by git and github, until the garbage collector kicks in.
The old answer doesn't work for me because I don't see Your Actions or Public Actions now.
My pending comments disappeared after I started typing into what I thought was a comment I'd opened for editing. It wasn't open, and one of my keys may have been a shortcut. I could still see the button to finish my review (including the count of my pending comments) but the comments had disappeared.
I eventually got them back by navigating to the pull request, then to the commit I was reviewing.

How to completely remove an issue from GitHub?

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.