search

evanchueng / gerrit

Automatically exported from code.google.com/p/gerrit
Apache License 2.0
0 stars 0 forks source link

Change the destination branch of an existing change #117

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by code-rev...@gtempaccount.com on 24 Sep 2009 at 7:36

GoogleCodeExporter commented 9 years ago

Original comment by sop+code@google.com on 24 Sep 2009 at 10:31

GoogleCodeExporter commented 9 years ago

Original comment by sop+code@google.com on 24 Sep 2009 at 10:53

GoogleCodeExporter commented 9 years ago 
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!

Original comment by dancys...@gmail.com on 19 Apr 2010 at 8:50

GoogleCodeExporter commented 9 years ago 
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?

Original comment by monica.d...@sonyericsson.com on 17 Dec 2010 at 12:38

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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.

Original comment by jaysoff...@gmail.com on 17 Dec 2010 at 3:38

GoogleCodeExporter commented 9 years ago 
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?

Original comment by monica.d...@sonyericsson.com on 20 Dec 2010 at 3:34

GoogleCodeExporter commented 9 years ago 
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.

Original comment by monica.d...@sonyericsson.com on 20 Dec 2010 at 5:15

GoogleCodeExporter commented 9 years ago 
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.

Original comment by em...@pete-woods.com on 6 Feb 2011 at 12:30

GoogleCodeExporter commented 9 years ago 
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!

Original comment by em...@pete-woods.com on 6 Feb 2011 at 12:32

GoogleCodeExporter commented 9 years ago 
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

Original comment by phil.hord on 19 Oct 2011 at 7:50

GoogleCodeExporter commented 9 years ago 
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?

Original comment by jaysoff...@gmail.com on 19 Oct 2011 at 8:19

GoogleCodeExporter commented 9 years ago 
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.

Original comment by mf...@codeaurora.org on 1 Jan 2012 at 5:59

GoogleCodeExporter commented 9 years ago 
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.

Original comment by bjoern.m...@gmail.com on 19 Jul 2012 at 3:21

GoogleCodeExporter commented 9 years ago 
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)

Original comment by Joel.DuB...@gmail.com on 19 Jul 2012 at 3:24

GoogleCodeExporter commented 9 years ago 
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.

Original comment by paulma...@gmail.com on 19 Sep 2012 at 5:14

GoogleCodeExporter commented 9 years ago 
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

Original comment by vo...@spotify.com on 5 Feb 2014 at 5:13

GoogleCodeExporter commented 9 years ago 
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.

Original comment by vo...@spotify.com on 5 Feb 2014 at 6:27

GoogleCodeExporter commented 9 years ago 
Can anyone please implement this? I would try if I had enough experience with 
Java...

Original comment by org...@gmail.com on 25 Aug 2014 at 12:45

GoogleCodeExporter commented 9 years ago 
#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".

Original comment by nic...@eriksson.cc on 20 Oct 2014 at 2:43

GoogleCodeExporter commented 9 years ago 
#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

Original comment by gustaf.l...@sonyericsson.com on 20 Oct 2014 at 3:02

GoogleCodeExporter commented 9 years ago 
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.

Original comment by nas...@codeaurora.org on 20 Oct 2014 at 10:33