Open GoogleCodeExporter opened 9 years ago
Original comment by sop+code@google.com
on 24 Sep 2009 at 10:31
Original comment by sop+code@google.com
on 24 Sep 2009 at 10:53
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
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
#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
#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
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
Original issue reported on code.google.com by
code-rev...@gtempaccount.com
on 24 Sep 2009 at 7:36