tl;dr I created a PR in someone's stead. Now I can't submit a review. Is there a way around?
The other developer messed up and merged a feature to the target branch, so I reverted their changes, fixed the issues, squashed and rebased their work while still keeping their authorship on the commit and I created a new pull request. Now, when I want to submit a review, it prevents me to Request changes, because now I am the author of the PR. How can I change it so that the other developer is responsible and receives the review?
You cannot change the author of a pull request or create one in somebody else's name. GitHub doesn't allow this because it would permit people to forge pull requests and let another person receive negative feedback. For example, if I opened a PR in your name containing something wildly inappropriate (say, a racist slur), you'd be blamed for it unfairly. Moreover, in some regulated environments, keeping an accurate record of who contributed code is very important for legal reasons, which is another reason why this isn't permitted.
In most cases, if a commit gets reverted, then just have the original author open a new PR. Clearly they'd wanted to submit the code in the first place. You can even create the branch for them with their commit squashed and prepared, as long as they open the PR. This is a case where a helpful conversation with another contributor goes a long way, and presumably you'd want to let them know in a kind way that they made a mistake and that you reverted it anyway. Since there's no way to create a repository on behalf of another user, you should close your PR and ask them original submitter to open it instead.
I think it's obvious why you can't approve your own PRs. I can see that this is a situation where requesting changes might be useful, but I suppose the rationale is that you wouldn't have opened the PR if you thought it needed improvements, and if you later learned that, you certainly would revise it instead of merging it.
Although bk2204's answer is correct and explains why there isn't a one-button solution, it doesn't address the actual question of:
How can I change it so that the other developer is responsible and receives the review?
The only way to that is to close out the PR you opened and have them open it instead.
Related
If I submit a pull request to Github with some changes..
And then someone edits those changes..
And I approve those changes to my PR..
And then want to make one more change to the same file..
If I go to edit the file (on the patch branch), I can see the proposed changes I have made, but not the ones I approved from the suggestions the other person made..
This makes it very confusing to know what is going to happen when the PR is accepted (if I add more changes), will the other User's changes get lost? are they added as separate patches? I'm not sure how to test this out other than setting up another github account and trying to recreate the scenario, but maybe someone can answer before I try that.
I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
I want to add a rule so the PR with open conversations can not be merged.
It occurs that I can find a typo in PR and add a comment and still approve the PR, so that an author has the opportunity to quickly correct this typo and merge the PR.
But I want it to be impossible to merge the PR until an author resolves the conversation.
Is it possible to do this?
It looks like they've added a branch rule option for this but it indicates that the functionality is still in Beta.
Simply go to Settings -> Branches and check the Require conversation resolution before merging field.
No, it's not possible to do that. Conversations and review comments aren't considered when performing merge checks.
If you want to prevent the PR from being merged, then you need to refrain from approving it or request changes if need be. The reason is that conversations can be resolved entirely by one party, so they aren't very effective at ensuring the user has done anything about them. The author could resolve it and merge without making any changes at all, and therefore it doesn't make sense to make this any sort of control.
On a Github project, I see a guy made a pull request in Pull Requests section, but I find he made many mistakes so his code need to be corrected. Instead of asking him to change his code, is it possible to do it by myself (that is, I want to correct his code by myself)? and how?
I'm also a member of that project, and I'm new :)
Enabling repository maintainer permissions on existing pull requests
Pull request creators can give these permissions on each of their pull requests when they initially create a pull request from a fork or after they have created the pull request.
On GitHub, navigate to the main page of the upstream repository of your pull request.
In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
In the right sidebar of your pull request, select Allow edits from maintainers. You can change these permissions at any time by unselecting this option.
More details on github help page: Allowing changes to a pull request branch created from a fork
TL;DR
Author of PR can modify an existing pull request to let repository maintainers make commits to your branch.
In order to allow you to make commits to others PR - the author has to set checkbox from the left:
Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[your.email#example.com: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing
I forked a repository (blog theme) on github, I want to make some changes to it and use it as my site, but I don't want to push those changes to the genuine repo, since the creator probably will not be interested, is that OK?, I mean will this brake any rules?, of course in my readme file I will give credits to the owner etc.
Should I just fork it or is better to clone it locally and then push it on Github as my own project, with credits to the legal owner.
Thank you
Unless they added you as a Collaborator on their repo, you wouldn't be able to push changes to the original (although you could submit Pull Requests).
It's probably more of an "informal rule" that you should fork, but you wouldn't be breaking any rules if you just made a new repo - unless you were violating the license or copyright of the original work.
A benefit of forking would be that you can more easily incorporate future changes to the original author's theme back into your fork (ex. if they fix something that you didn't notice was broken, future new standards compatibility, etc.)
Other benefits of forking include: let the original author know that their work really was useful to someone and let others see that it has been forked, thus validating the usefulness of the work if they're considering using the original work, etc.
So, while the original author might not be interested in your work specifically, there are benefits to you and the community to forking.