Issue 117: Change the destination branch of an existing change
Reported by code-rev...@gtempaccount.com, Sep 24, 2009
Reported by Brian Swetland <swetland@android.com> on Fri Mar 27 19:09:28 PDT 2009
Source: JIRA GERRIT-117
Affected Version: 2.0.9

Provide a way to retarget a patch to a different branch.

Because the parent changes, this requires cherry-picking the patch onto the
other branch, even if the project's submission policy isn't to merge.
Sep 24, 2009
#1 sop+code@google.com
(No comment was entered for this change.)
Status: Accepted
Owner: ---
Sep 24, 2009
#2 sop+code@google.com
(No comment was entered for this change.)
Cc: swetl...@android.com
Apr 19, 2010
#3 dancys...@gmail.com
Question to the original submitter.   Is this the scenario you're talking about?

git push gerrit HEAD:refs/for/v1.0

Time passes, the change hasn't been submitted yet, v1.0 has entered code freeze and 
v1.1 is now an available branch:

# Reissue against v1.1 instead
git push gerrit HEAD:refs/for/v1.1

Is that what you want to work?  If so, me too! 

Dec 17, 2010
#4 monica.d...@sonyericsson.com
Hi, I would like to know if is the scenario above that you (original submitter) were talking about. I have some questions about that too:
1. Are you talking about modifying the destination branch of the change or of the patch?
2. What would happen if the patch or the change has dependencies?
Dec 17, 2010
Project Member #6 jaysoff...@gmail.com
Here's my use case:

git checkout -b feature origin/master
edit, commit
git push origin HEAD:refs/for/master
... time passes ....
git rebase origin/release
git branch feature --set-upstream origin/release
git push origin HEAD:refs/for/release

It would be nice for that second push to change the target branch. Currently, I have to abandon the change, or edit its target branch via gsql.

Dec 20, 2010
#7 monica.d...@sonyericsson.com
Hello! So, what you want is to update dest_branch_name in table changes to the new target branch, right? In your use case it will be updated from refs/heads/master to refs/heads/release. Is it ok?
Dec 20, 2010
#8 monica.d...@sonyericsson.com
Shawn, Ulrik asked us to take a look on this issue. If nobody is working on this could you set Ulrik as owner of this issue? So, we will work on this.
Feb 6, 2011
#9 em...@pete-woods.com
The method described in comment #3 is definitely the sort of thing I'd like. Being able to do it in the GUI would just be icing on the cake for my needs.
Feb 6, 2011
#10 em...@pete-woods.com
I should point out that I use CHERRY_PICK as the submit type for all my projects, so I guess that's the easiest case for this particular issue!
Oct 19, 2011
#11 phil.hord
We use the existing behavior to submit identical changes for multiple branches.  Please don't break it.

Maybe a new "magic target" could be invented for this feature.  Something like 
  git push origin HEAD:refs/movetobranch/release


Here's my use case -- does what I need today.  Does this satisfy the original poster's need as well?

git checkout -b feature origin/release-2.0
edit, commit
git push origin HEAD:refs/for/release-2.0
... review, verify, submit ...
... Management decides to backport the change to maint-v1.9
git checkout origin/maint-v1.9
git fetch origin refs/changes/88/688/2 && git cherry-pick FETCH_HEAD
git push origin HEAD:refs/for/maint-v1.9


Oct 19, 2011
Project Member #12 jaysoff...@gmail.com
When this issue was originally opened change-id's needed to be unique across all branches. Since then Gerrit has changed such that the uniqueness is on (change-id, branch). 

So it may no longer make sense to change the destination branch via push. (Arguably, you'd rebase a change locally before changing its branch in gerrit, but not necessarily.) Perhaps "gerrit review --branch BRANCH" via the CLI instead?

Cc: -notbrian...@gmail.com
Dec 31, 2011
Project Member #13 mf...@codeaurora.org
I have started working on this.  My intent is to start by simply allowing a target branch to be changed via the WUI.  I will add an edit icon next to the current branch entry which will bring up a comment dialog with a dropdown with branches to which the user is permitted to upload to. 

While I do not plan to fix this, eventually it would be nice to deal with dependencies in an intelligent way.  But, since there are already many ways to mess up a change's depedencies, I don' t feel that it makes sense to hold up this simple option for that reason, especially since there is likely no easy single simple solution.  Some ideas would be to allow an entire graph to be moved, to allow a graph to be severed at any point and moved (and thus rebased), and also to be severed at any point while copying the ancestors above that point to the new branch and to move the ones below it.
Status: Started
Owner: mf...@codeaurora.org
Jul 19, 2012
#14 bjoern.m...@gmail.com
Re Comment 12: "Since then Gerrit has changed such that the uniqueness is on (change-id, branch)."
Has it? In gerrit 2.4.2, I still see the problem that you cannot review the same Change on multiple branches.

Jul 19, 2012
#15 Joel.DuB...@gmail.com
We have that same issue. Once you close a change-id by merging it, you can no longer update the same change-id that points at a different branch. (Change ID is closed and cannot be updated)
Sep 19, 2012
#16 paulma...@gmail.com
Is there any word if this will be fixed permanently? As of 2.4.1, this behavior still exists. 

Really this is more important than it sounds (I disagree that it is minor). A "patch" may be across multiple branches and multiple releases, and while we could --amend it that becomes wasteful. I would prefer to be able to make an association of a change to a product fix, and not track n+1 sha1 values for reporting reasons. 

We may have a product in the field that is years old, and cherry picking changes to bring it up to date and changing sha1 values for all of them seems like alot of work for a simple key change.



Feb 5, 2014
#17 vo...@spotify.com
17 months later; What's the real status of this issue? 
Here's my use case: 

work with large team on a large codebase
Do some work
push for review on master
do some more work depending on the previous work
push for review on master
Do even more work depending on the previous commits, while waiting for the previous ones to be reviewed
push for review on master
Reviews are done, starting to merge, realise you are in rebase hell because you have ff-only, wish you had done the work on a feature branch as you should.

Would be oh so sweet to be able to simply move the reviews to a branch

Gerrit 2.7-30
Feb 5, 2014
#18 vo...@spotify.com
By the way; Gerrit still tells me, in version 2.7-30, that issue is closed/no changes if I try to push the same commit with same change-id to different branches. 
Aug 25, 2014
#19 org...@gmail.com
Can anyone please implement this? I would try if I had enough experience with Java...
Oct 20, 2014
#20 nic...@eriksson.cc
#18: "By the way; Gerrit still tells me, in version 2.7-30, that issue is closed/no changes if I try to push the same commit with same change-id to different branches."

Same issue in Gerrit 2.9. Would be very nice to have this fixed!

This "workflow" is also problematic with current implementation:
* Push something to wrong branch.
* Realize mistake and abandon change-set.
* Try to push to correct branch - Reject because of "no new changes".


Oct 20, 2014
Project Member #21 gustaf.l...@sonyericsson.com
#20: This is fixed by Deniz here:
https://gerrit-review.googlesource.com/#/c/59909/

and tracked in this issue:

https://code.google.com/p/gerrit/issues/detail?id=1195

Oct 20, 2014
Project Member #22 nas...@codeaurora.org
We have something for this that's 2.5 based. We'll be working on porting to tip and getting it upstreamed in the future. If someone else wants to do the porting work we can share the 2.5 version sooner.
Oct 22, 2015
#23 fabio.po...@gmail.com
1 year later: There is any good news about this feature?

Any code to try?

Thanks

Oct 22, 2015
Project Member #24 mf...@codeaurora.org
Here is some code: https://gerrit-review.googlesource.com/#/c/71480