Answers.Body: <p>You can add a second commit and push to the same branch, which is what I'd generally do. The PR will be updated with additional commits to the PR's branch. </p>
  
  <pre><code>git add --patch
  git commit
  git push REMOTENAME BRANCHNAME
  </code></pre>
  
  <p>If your branch hasn't been merged (and you're not concerned about others having worked on the same branch), you can also amend your commit and then force-push. But this is more likely to cause grief IMO. </p>
  
  <pre><code>git add --patch
  git commit --amend
  git push -f REMOTENAME BRANCHNAME
  </code></pre>
  
  <p>If you really regret a PR, you can delete the remote branch and start over. This will probably destroy the PR, but you can make as many branches and pull requests as you like.</p>
  
  <p>A colon before the branch name will push "nothing" to that branch, deleting it.</p>
  
  <pre><code>git push REMOTENAME :BRANCHNAME
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-12T09:25:26.047Z
Answers.Text: I have had problems pushing the second commit to the remote branch. I forget the exact error message.  So, it seems easier to close the PR, delete the remote branch and start again.  Next time I have to do a PR, I'll have another look.
Answers.UserDisplayName: Stephen Palmstrom
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-04T18:33:39.027Z
Answers.Text: I have found that once your forked master gets behind Civicrm/civicrm-core master the only way round is to delete your fork and clone from the CiviCRM repository, re-apply the changes and hope the master isn't out of date before submitting the PR.  I have tried various forms of rebasing, but none seem to work.  Any suggestions?  Submitting PRs takes much longer that fixing the code, and the risk is that you get the changes wrong after so much fiddling around.
Answers.UserDisplayName: Stephen Palmstrom
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-10T21:49:21.607Z
Answers.LastActivityDate: 2016-10-11T00:51:59.933Z
Answers.LastEditDate: 2016-10-11T00:51:59.933Z
Answers.UserDisplayName: Chris Burgess
Body: <p>I have found that the best way to deal with pull requests that have failed validation due to coding standard error is to close the PR, delete the remote branch in Git and create a new one with the corrected code pushed to it.  This is, of course, a bit fiddly and one would rather get the standards right first time. Is this the correct approach?  Simply pushing a new commit causes grief in that the local and remote branches are out of sync.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-10T21:49:37.467Z
Comments.Text: I don't understand what you mean by "causes grief", can you be more specific?
Comments.UserDisplayName: Chris Burgess
Tags: <developer>
Title: GitHub Pull Request errors
ThreadText: # GitHub Pull Request errors
  
  (Asked by: username_0 on 2016-10-10)
  
  I have found that the best way to deal with pull requests that have failed validation due to coding standard error is to close the PR, delete the remote branch in Git and create a new one with the corrected code pushed to it. This is, of course, a bit fiddly and one would rather get the standards right first time. Is this the correct approach? Simply pushing a new commit causes grief in that the local and remote branches are out of sync.
  
  **Tags:** developer
  
  > **Comments:**
  > **username_1**: I don't understand what you mean by "causes grief", can you be more specific?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-10-10. Score: 2
  
  You can add a second commit and push to the same branch, which is what I'd generally do. The PR will be updated with additional commits to the PR's branch.
  
  ```
  git add --patch
  git commit
  git push REMOTENAME BRANCHNAME
  
  ```
  
  If your branch hasn't been merged (and you're not concerned about others having worked on the same branch), you can also amend your commit and then force-push. But this is more likely to cause grief IMO.
  
  ```
  git add --patch
  git commit --amend
  git push -f REMOTENAME BRANCHNAME
  
  ```
  
  If you really regret a PR, you can delete the remote branch and start over. This will probably destroy the PR, but you can make as many branches and pull requests as you like.
  
  A colon before the branch name will push "nothing" to that branch, deleting it.
  
  ```
  git push REMOTENAME :BRANCHNAME
  
  ```
  
  > **Comments:**
  > **username_0**: I have had problems pushing the second commit to the remote branch. I forget the exact error message.  So, it seems easier to close the PR, delete the remote branch and start again.  Next time I have to do a PR, I'll have another look.  
  > **username_0**: I have found that once your forked master gets behind Civicrm/civicrm-core master the only way round is to delete your fork and clone from the CiviCRM repository, re-apply the changes and hope the master isn't out of date before submitting the PR.  I have tried various forms of rebasing, but none seem to work.  Any suggestions?  Submitting PRs takes much longer that fixing the code, and the risk is that you get the changes wrong after so much fiddling around.  
  
  ---
  
  