Issue 1142: auto closing change after pushing to any branch
Status:  New
Owner: ----
Reported by pkufra...@gmail.com, Sep 27, 2011
Affected Version: 2.2.1

What steps will reproduce the problem?

After submit for review, i push the commit to a sandbox branch for
backup. This causes the change closes unexpectedly and i can't submit
for another iteration of review.

Can gerrit be more clever? For example, it closes the change only when
the code is pushed to the corresponding review branch.

Following is my workflow, any suggestion?

1. commit and submit for review (for master)

$ git commit -a -m "Test change close"
$ git push origin HEAD:refs/for/master
...
remote: New Changes:
remote:   http://bear/gerrit/996
...

2. backup code to server (causing change closed)

$ git push origin HEAD:sandbox/backup

3. amend the change and can't submit review again

# make some changes
$ git commit --amend -C HEAD
$ git push origin HEAD:refs/for/master
...
! [remote rejected] HEAD -> refs/for/master (change 996 closed)

What is the expected output? What do you see instead?

The changes shouldn't be closed if pushing to a non-target branch.

This is the same with  issue 635 . 635 was fixed in 2.1.7, but it seems that this issue reopens in 2.2.1

Oct 28, 2011
#3 zu.bruce.china@gmail.com
Hi Ping Yin
I want confirm with you about this issue in detail.
I triggered this issue today by below steps. will please review my comments in it?
if my understanding is right. I will begin trying to fix it.

 
 2548  ssh  bruce.zu@localhost  -p 29418  gerrit create-project   --name  project-test  --empty-commit
 2549  git clone ssh://bruce.zu@localhost:29418/project-test
 2550  cd project-test/
 2551  echo "a" > f.txt
 2552  git add f.txt
 2553  git commit  -m "a------base commit on the empty commit "
 2554  git checkout -b local-branch
 2555  git push ssh://bruce.zu@localhost:29418/project-test HEAD:refs/heads/master
 2556  git push ssh://bruce.zu@localhost:29418/project-test HEAD:refs/heads/sandbox/backup
      [comments:
       above steps are about background. am I right?
       now begin test as your steps. 
      ]
 2557  vi f.txt
 2558  git commit -a -m "Test change close"
 2559  git push origin HEAD:refs/for/master
 2560  git push origin HEAD:sandbox/backup
      [comments:
       here I watch the Gerrit UI page and find the change is in "merged" status.
       so I think here is the place where this issue happens. am I right?
      ]
 2561  vi f.txt
 2562  git commit --amend -C HEAD
 2563  git push origin HEAD:refs/for/master
      [comments:
       no error here, this command create a new change.
      ]
 2564  git push origin HEAD:refs/changes/master
      [comments:
       find error here. as the this issue has happened and the change has been in 'merged' status .
      ]
 2565  history

Oct 28, 2011
#4 leem...@gmail.com
Hi zu.bruce,

I have the same problem. Here's my review for your steps:

> 2559  git push origin HEAD:refs/for/master
(Gerrit create a new change for this new commit)

> 2556  git push ssh://bruce.zu@localhost:29418/project-test HEAD:refs/heads/sandbox/backup
>      [comments:
>       above steps are about background. am I right?
>       now begin test as your steps. 
>      ]
(when you push that commit into repo directly, the corresponding change will be closed accidentally, and that's the bug)
Oct 28, 2011
#5 pkufra...@gmail.com
hi, zu.bruce, leem...

>> 2556  git push ssh://bruce.zu@localhost:29418/project-test HEAD:refs/heads/sandbox/backup
>>      [comments:
>>       above steps are about background. am I right?
>>       now begin test as your steps. 
>>      ]
> (when you push that commit into repo directly, the corresponding change will be closed accidentally, and that's the bug)

Yes, that's the bug.

The triggering steps are right.
Oct 30, 2011
#6 zu.bruce.china@gmail.com
Hi, Leem
 in your feedback, you use line 2556 to replace line 2560 in my steps.
 careless error or intentional? 
 make me a little confused.
 
 if I am not wrong, the expected result is:
 after line 2560  "git push origin HEAD:sandbox/backup"
 on the Gerrit UI page the change(on master branch in my case) should not be changed to "merged" status/ your words "be closed".

 
Oct 30, 2011
#7 leem...@gmail.com
Hi zu.bruce,

it's my careless mistake. I wanted to use the 2555 line instead of 2559 line. in fact, the bug should have been  triggered after 2556 line.
Nov 6, 2011
#8 egrumbach
BTW, the W/A is to recreate the commits with git rebase
Nov 8, 2011
Project Member #9 bruce.zu@sonymobile.com
Hi Egrumbach
what is the meaning of "the W/A is to recreate the commits"? 
I just fixed this issue and the commit is under review now. 

Nov 8, 2011
#10 egrumbach
Hi,

by "recreate the commit", I mean git rebase --no-ff.
I must admit I have no cycles to build gerrit by myself, so I only use releases. I know that a lot of people hack on the code to have the features / bug fixes they need, but my employer expects me to develop other things and not gerrit :-)
If 2.2.2 will fix this issue, I will more than happy :-)
Nov 8, 2011
Project Member #11 de...@spotify.com
The attached patch aims to resolve this issue. It closes the change if and only if the branch names are the same.
Nov 10, 2011
Project Member #13 bruce.zu@sonymobile.com
thanks sharing this patch. I have fixed this issue also in my patch which is not same as the above one which I have test and find :

1> 'push ... refs/for/reviewbranch'
ok

2>'push ... refs/heads/sandbox'
ok

3> merge the change from WebUI.

not ok .
WebUI: merged but in pending status
Gerrit server log: find errors.

Dec 25, 2011
Project Member #14 de...@spotify.com
Thanks for letting me know the bug Bruce. It is now fixed, the updated patch is attached.
1142.patch
2.4 KB   View   Download
Feb 14, 2012
#15 egrumbach
Are there any plans to merge a fix for this issue in a future release ?
Feb 17, 2012
#16 phil.hord
I have tested this latest patch with v2.2.2 it works fine for me.  Thanks, and +1.

Now I'm working on finding all the "lost" patchsets that got dropped from the review queue when they were "merged" to sandboxes in the past.  Looks like we have several in our repo.
Feb 20, 2012
#17 egrumbach
Deniz Türkoglu just uploaded a fix:
https://gerrit-review.googlesource.com/#/c/32881/
Feb 23, 2012
#18 georgey21
The code in MergeOp.java breaks review submit/merges by marking non-desination-target branches as unacceptable, which in turn hides previously merged dependencies and lists them as missing.
Jul 15, 2012
#21 bjoern.m...@gmail.com
In 2.4.2 this behaviour is particularly inconsistent: One can submit a change to multiple branches with the same change-id, but this is not possible anymore once it is merged in any of them
Nov 26, 2012
Project Member #23 bklarson@gmail.com
 Issue 1329  has been merged into this issue.
Feb 28, 2013
#24 rasmuskv...@gmail.com
I think this still exists somehow or at least very similar error.

gerrit version 2.5.2-1-g0b0dbb0
git version git version 1.8.1.msysgit.1

what i do is this. 
git checkout develop
echo "Fish, Water, gravel, plants, water" >fishtank
git add fishtank
git commit -m "My brand new fishtank"
git push origin HEAD:refs/for/develop

Then i do 
git push origin HEAD:refs/heads/topic/fishtank
Then on the open change this comments pops up 

Change has been successfully pushed into branch topic/fishtank.
and status has changed to merged. 

My problem is that i cannot from the webui, merge it to develop at all, as the status is merged.

/Rasmus Voss




Mar 4, 2013
#25 phil.hord
I agree this problem still exists, at least as of v2.5.1. That's why it is still marked "New" instead of Closed/Resolved.
Apr 15, 2013
#26 duncan.a...@gmail.com
This is a serious issue for us, the work around would be to modify the changeids for all commits which have been merged into the other branch, and re-commit them to the branch they were 'stolen' from.

I think the changeId should be unique to that branch, it shouldn't be possible to switch the branch of a changeId once created.
May 16, 2013
#27 cunm...@lytro.com
Still seeing this on 2.5.2
May 16, 2013
#28 duncan.a...@gmail.com
still on 2.5.1, I will upgrade tomorrow and let you know.
Jan 10, 2014
#29 aspr...@gmail.com
I am seeing the same issue on 2.6.1. Below my question posted on the repo-discuss group.

---8<-------------------------------------------------------------------------------

We use gerrit on a daily basis and just recently I noticed something
unexpected. In our gerrit project we have a scratch/sandbox where
users can push their branches (for backup or whatever). So here is
what happened to me (A=Action, R=Result):

A1. I pushed a change for review: git push gerrit HEAD:refs/for/target-branch
  R1: A new change X is added for branch 'target-branch'
A2: push change to scratch area after rework: git push gerrit
HEAD:refs/heads/users/tmp
  R2: I have a users/tmp branch on the server
A3: update the change with rework patch: git push gerrit HEAD:refs/changes/X
  R3: change X state changed to Merged with comment:
      "Change has been successfully pushed into branch users/tmp"

R3 is unexpected and the comment added to the change gives the
motivation but I would expect it only to change to Merged when the
change ends up in the 'target-branch' indicated in A1. For my use-case
this looks like a bug, but there may be other reasons for this
behaviour.

Regards,
Arend
Oct 7, 2014
#30 tobiassc...@googlemail.com
Any updates on this issue?
Apr 7, 2015
#33 altmann....@gmail.com
anyone working on this issue? 
Jun 10, 2015
#34 crlf0...@gmail.com
This issue is a serious problem for us. Please raise its priority!
Oct 21, 2015
#35 nuy.1234...@gmail.com
ชช"+1 Me too! Issue_subscribe.html