| Issue 2028: | Wrong commit in ChangeMergedEvent when submit type is rebase | |
| 5 people starred this issue and may be notified of changes. | Back to list |
Gerrit will send ChangeMergedEvent with incorrect patch set revision when submit type is set to 'rebase if necessary' and rebase occur. Steps to reproduce: 1. create two independent patch sets (assume commit id's like abc123 for first patch and 098cdf for second one) 2. push them for review 3. submit first one - you will get ChangeMergedEvent with patchSet.revision = abc123 4. submit second one - gerrit will handle rebase for you (will create commit eg. 456bcd) - you will get ChangeMergedEvent with patchset.revision = 098cdf, which is a bug this variable should be set to 456bcd since this commit was actually merged
Dec 5, 2013
I have encountered something very similar to this issue on Gerrit 2.8. I double-checked the version we upgraded from, 2.5.1, and that version had the expected behavior.
Here are my steps to reproduce in a project with Submit Type: Cherry Pick:
1. Push a commit for review which creates a new change with patchset 1, abc123
2. Push another patchset on the same review, patchset 2, bcd456
3. Submit the change, which automatically creates patchset 3, cde789
4. Observe gerrit stream-events for the change-merged event.
Actual result (bug): The event json contains:
"patchSet": {
..
"number": "2",
"ref": "refs/changes/89/8989/2",
"revision": "bcd456",
...
}
Expected Result: The event json contains:
"patchSet": {
..
"number": "3",
"ref": "refs/changes/89/8989/3",
"revision": "cde789",
...
}
Dec 9, 2013
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |
Labels: FixedIn-2.8