Change Pull Request Target Branch
It would be great to be able to change the target branch of a pull request. Sometimes a pull request is simply opened against the wrong branch. Other times, the comments and discussion resolve in wishing to integrate with a different branch prior to promoting to the original target.
Any official word on this being implemented? I am actually debating moving to GitHub because this happens so frequently.
Trinh Pham commented
The scenario I met is: We have a release[Ver] branch where all Developers target their pull requests to it.
When the release[Ver] is locked for releasing, new release[Ver2] is created for next release. All uncompleted PRs need to re-target to the new branch.
Abandon & re-create causes loosing all the comments.
So, implement this feature like Github is really good and solve our problem.
Official branch locked for the foreseeable feature. 40+ developers asked to move all their PRs to a different branch, identical (i.e. same commit) as the official.
Now everybody needs to abandon their PRs and recreate them, losing comments, etc.. Please implement this. Thanks.
Similar issue to Peter here. Very difficult to have multiple PR's out simultaneously when some of those PR's build off of previous PR's. Either you target them all to master and they include each other in the diff, or you target them at each other and have to recreate the PR later in a very nasty fashion.
Root issue is dependent PR, so anything that can fix that works for me.
+1 This just happened to me as well...
This would be so much easier and cleaner than having to abandon and make a new one since that loses all the code review history as well. I find this happening multiple times a month.
Agreed. This would greatly simplify my workflow when changes need to be promoted from "scheduled for next release" to "critical release." Currently that requires abandoning the existing pull request and creating a new one just to skip our prerelease branch. If we could directly move pull requests between the two branches, it would be much better.
Peter Kurlak commented
Not having this feature prevents taking advantage of the true power of the Git workflow: being able to work on and receive reviews for multiple things at once. Before I knew of this limitation, I created a PR against a branch other than master. It was awesome! My coworkers were able to provide feedback on code that depended on another branch not yet in master. After some dialog, they approved my changes. When I had received all my approvals and the owner was ready to review, I suddenly discovered this problem. Now I had to "throw" away a perfectly good PR and create a new one against master. The comments and approvals obviously did not transfer. Thus, I had to ping everyone that had previously approved the code to do so AGAIN (developers hate repetition), and then the code's owner had to reference the previous PR. And what if he wanted to add comments? Should they go on the previous PR or the new PR? What a mess. This needs to be fixed ASAP!
Thomas Piart commented
We also do have the same scenario as @Vivek
Vivek A Maharajh commented
My use case involves working on a new pull request that depends on the commits of an existing pull request.
I create a pull request from branch A into master.
While it is being reviewed, I start working on a change that depends on the commits in A, so I create a new branch B based on A. I now create a pull request from branch B into branch A. I never intend to merge into branch A — I intend on merging into master **after** the initial pull request is merged into master.
After the initial pull request completes, I'd like to change the target branch for the second pull request to be master.
Fabien Crassat commented
Github just did it (https://github.com/isaacs/github/issues/18) so it will very great to have it too :)
Sean Lee commented
Seconded, for want of correcting an error or adapting to late-breaking evolution