Issue 2252: Many "unwanted" changes when merging between repos and pushing to refs/for
Status:  New
Owner: ----
Reported by duft.mar...@gmail.com, Nov 12, 2013
Affected Version: All AFAIK, tested with 2.6.1.

What steps will reproduce the problem?
1. Have two repositories containing the same software base. In our case we have a production repository and a developer repository. The separation is to keep the production repo clean branch-wise. The developer repo contains hundreds of branches.
2. Create a developer branch in the developer repository, starting from production master. Create some commits on production master and on the developer branch.
3. Merge production master to developer branch.
4. Push to refs/for/developer_branch on the developer repo.
5. Gerrit will create review items for all commits merged in from master.

What is the expected output? What do you see instead?
I'd expect to either reject or not create review items for changes already processed, even though it was a different repository (on the same gerrit instance!). The way it behaves now, i get the changes a "second" time (yes i know, different repo...). Now developers usually don't want to review those things again and start abandoning, which is the worst thing they could possibly do; this will break all other developer branches that also have merged in from master (even though they pushed it correctly to refs/heads/their_branch). Gerrit will refuse all following up changes as they depend on an abandoned change :(

The only way out of this is to gsql to the H2 database and delete the offending changes. I already have all statements at hand because this happens rather regularly (we have some not-so-string-devs)...

Please provide any additional information below.

The way i cure this situation is:
1) find out the users user_id;
2) fetch all open changes for this user, refine the result set until i got a select query that returns only the bad ones.
3) change the selete to a delete from changes where .... blahblah
4) fire those to fixup the rest of the DB:
delete from account_patch_reviews where change_id not in (select change_id from changes);
delete from change_messages where change_id not in (select change_id from changes);
delete from patch_comments where change_id not in (select change_id from changes);
delete from patch_set_ancestors where change_id not in (select change_id from changes);
delete from patch_set_approvals where change_id not in (select change_id from changes);
delete from patch_sets where change_id not in (select change_id from changes);
delete from starred_changes where change_id not in (select change_id from changes);

I also tried to reproduce this in a smaller environment, but somehow i was unable to come up with the "correct" constellation to trigger the bug :(

I will keep trying to come up with something small i can share. However you might already have an idea whats wrong :) (btw. we talked about that one @EclipseCon Europe...)