| Issue 117: | Change the destination branch of an existing change | |
| 83 people starred this issue and may be notified of changes. | Back to list |
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
(No comment was entered for this change.)
Cc:
swetl...@android.com
Apr 19, 2010
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
Can anyone please implement this? I would try if I had enough experience with Java...
Oct 20, 2014
#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
#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
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
1 year later: There is any good news about this feature? Any code to try? Thanks
Oct 22, 2015
Here is some code: https://gerrit-review.googlesource.com/#/c/71480 |
|
| ► Sign in to add a comment |
Owner: ---