Last modified: 2014-02-22 19:17:00 UTC
See https://gerrit.wikimedia.org/r/47089 I used git-review to upload patch set 6. Then, accidentally, without refreshing my windows to see the new patchset, I changed the commit message to add a bug number. Rather than producing some error message or the like, it changed the commit message of patch set 5 and made it patch set 7, effectively undoing the in between patch.
Mhmmm. As your browser window was still at patch set 5, it looks like expected behaviour to me. I would not want gerrit to second guess the one who edited the commit message of patch set 5 or even forbid editing the commit message in that case.
How is that expected? It'd be like committing a database transaction where the data has changed since it was last read, or a more appropriate example: having a edit conflict on Wikipedia be resolved just by overwriting the last revision. The correct behavior would be to display an error saying there was an edit conflict.
No, not necessary. Our last patchset is patch set 5 which is revision bbb123 based on parent aaa456 One developer submitted patch set 6 (revision ccc789) based on the parent revision aaa456 as well. Then another developer edits something which means submitting independent patch set 7 based on the parent revision aaa456 as well. It can include stuff from patchset 5 but does not have to. All patchsets are independent "children" of the parent. Sometimes parents differ when you "rebase" your stuff. One can squash (merge) few changes into one - I would checkout patch set 6 and then checkout patch set 7 by using "git cherry-pick -n" without using another commit. You can use "git-review -X change,patchnr" for that.
*** Bug 59892 has been marked as a duplicate of this bug. ***
I ran into the exactly same problem on gerrit: 111943. It's so annoying.
