I would like to make a pull request from my fork repo to the upstream repository.
As always I was following these steps here from the guidance from Github.
But this time I can not make a pull request, as the button is disabled.
The branches can be automatically merged.
I do have changes in my forked repo and I can see commits made.
Base repo and head repo are indicated correctly.
In my case, the pull request Title field didn't auto-populate like it usually does. Once I typed in a title, the button became active.
From Github Developer Support:
Also, I know this might seem strange, but could you try selecting the
base repo/branch from the drop down list (even if this already seems
selected), and give this another go. It could that, for whatever
reason, the pull request creation flow isn't picking this up
implicitly.
I have also logged out and logged in again.
After that, everything was fine!
make sure to put something in the title, I forgot to add one here
Populating the "comment" field did it for me.
I couldn't see a button at all... and then I realised...
I wasn't logged in #facepalm
It happened to but I realized that and immediately changed the default branch to master. The pull request button got activated thereoff.
After realising it's just a HTML issue, I enabled the button by inspecting the element and deleting the tag in my browser (Safari).
That should fix the issue in other browsers too.
I had to select my branch from the list shown down on the github page labeled "There isn’t anything to compare." - weird but worked fine.
I had the same issue. Adding a title to pr fixed the problem
Related
I have a PR where I left several comments in my review on GitHub
A colleague has updated the code to apply my suggested changes, and now all my review comments appear with the outdated label.
However I still see the code in the state it was when I commented it.
What I want is an easy way to see the new code he has written, not the old. Is it possible at all?
Open the PR and Click on the files changed tab. All the latest changes that have been pushed to the branch requesting the PR will be available.
I pushed a PR.
A reviewer asked for changes.
I make changes and push again.
I would like to be able to see only my new changes since his review on github to make sure I did what I was supposed to do.
Atm I can't because I haven't reviewed it yet (option disabled). Only the reviewer can click on it:
Is there a way to view it?
You should be able to see individual commits from "Commits" tab.
One way to do it is finding out the commit when the review took place and then compare it to your commit by manually editing the url and adding 2 dots between commit ids, like this
https://github.com/user/repo/compare/c3a414e..faf7c6f
source: https://help.github.com/articles/comparing-commits-across-time/#comparing-commits
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.
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.
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.