Someone asked me to do this: create an issue on your repository and add our Github handles to the issue body (#name1 and #name2) so we can review your submission.
I used the github software on windows7 and uploaded my source, then went to github.com and created an issue, and then added the above to what I believe is the "issue body."
I believe I've done it correctly, but given github's wierd lingual and it's unintuitive use, I have some doubts. I even had issue signing up an account with them as it gave no errors what was wrong. needless to say, github has been really irritating.
Please see this image and let me know if this is done correctly:
https://drive.google.com/file/d/0BxTAvARlh78dbXJGckRzS01oNVk/edit?usp=sharing
Thank you.
See #mentions on Github (which I believe is what you want):
https://github.com/blog/957-introducing-issue-mentions
https://github.com/blog/821
Related
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.
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
I am checking out code using GitHub client for Windows. When I press "clone" button in browser, it looks like I have a local copy. However, there are a few files that GitHub is asking me to commit. Now, I have not even made any changes to anything on my local. So why is it asking me to "commit"?
Can anyone tell me why I am facing this problem. Also, are there any good GitHub tutorials to follow?
Thanks in advance,
There is a great github tutorial here, that should get you started with the basics: http://rogerdudler.github.io/git-guide/.
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.
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.