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.

Hi I carnt be 100% sure but I think this was fixed in the upgrade to gerrit 2.12. Please could you re try to see if it is fixed for you please?

No, this is not fixed as you can always create a patch based off of an old one. It's probably a little bit harder to do it accidentally now since it's integrated into the online editor.

Doing it accidentally was kind of lame, but it was never really a bug tbh.