I have pushed two changes to AOSP, same topic and they have been sitting with "Needs Code-Review Label" for 3 days now (weekend included).
I know I can assign reviewers manually, but I wouldn't know who to add. I've read around on how to submit a patch but have not found if reviewers are automatically notified and the change will be processed whenever it should or if there is something else on my side I have to do.
You just need to wait or you could, if was the case, add specific reviewers for your change. It's seens that 3 days (weekend included) aren't time enought for the review.
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.
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.
I have a GitHub action that evaluates something and then creates a Status Check with the result.
setup is the one that evaluates and linting is the result (a different status check with all the information). This is done because the default status check is only the logs, but if I create a second one, I can format it with Markdown.
The problem I have is that, when the action is executed to the same commit (because the Pull Request was modified by changing title, reviewers, etc) the action is executed again, which is intended, but creates a second setup check that doesn't disappear. This will accumulate for as many modifications I make.
The old linting status check, instead, will be replaced by the new one, so I don't have any problem with that.
Is there any way to hide the setup check once it's completed? Or to completely hide it? I would prefer to show it while it's running, but once it's finished it should hide itself to keep the PR clean.
This appears to be a bug. Your best plan of action is to contact support#github.com regarding this bug. Make sure you mention how to reproduce this bug (or even link them to this SO post).
As this doesn't appear to have any adverse effects (other than potentially cluttering the screen), it shouldn't be that big of a problem, but I'd definitely reach out to Github.
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
We are working on a single project, and also committing code at the end of day on SVN so that can get all update project. But issues is very often our code getting errors while committing code and projects get empty if someone get update at that time. So my question is are there any set of rules which we've to follow on committing so that every one go on straight path and no one get in trouble and save a lot time from these errors.
Thanks in advance. Cheers
Search Google, something similar to "source control best practices".
Top result has several tips. Sounds like the biggest problem you're facing is integrating with others' changes. Perhaps look into the following sections:
Incorporate others' changes frequently
Share your changes frequently
Coordinate with your co-workers
Investigate why you get errors. Blind application of rules is not good.
For example:
person A committed a code producing compilation error
why?
he finished his task, but hasn't checked build before committing to the trunk
why?
the entire build it too slow
solution: speed-up build, set up continuous build system which will check every commit and notify developers about problems as soon as possible
Another example:
person B committed a code which breaks the build
why?
he wanted to store his changes, but the task is not finished
solution: advice him to create a branch, when the task is finished it can be merged to the trunk (if branch lives for long time, merge changes from trunk to it periodically, then the merge will not be a problem)
There possible other scenarios. With more details you will be able to ask more precise question on StackOverflow and get better answers.
In case of use of SVN co-ordination is must between the team.
Make sure whenever you commit the code you have a idea about what are you committing.
The golden rule is "One developer One class".
If at all two different developers are working on same class. Ask them to maintain a document on what changes they have made. And, most important to mark a comments in a class it self.
There are some important things which need to be followed while committing the code. Whenever you see a conflict in your local files and server files. Make sure you go through every conflict and select the appropriate action.
Understand one important thing, whenever SVN is used one persons mistake can affect everyone.
Whenever possible, don't edit the same line of code as someone else
Leave meaningful comments on your commit messages
Comment your code
Make sure that all the code you commit compiles and runs as it should
Commit when appropriate ie: are passing off part of your code to be used by others or are done working on a feature
Make sure to communicate with other team members
If you find code that you don't know what it does, ask the author
If you're making major changes that will take a while to implement, use a branch and then merge it back in