Hi Peter,
By "keep an overview" I mean to know which commits in a pushed branch that have been reviewed and which not.
Ah, ok; I'd assume that Gerrit won't allow pushing a series of patches if one patch in there doesn't have +2 and +1 verified yet. Haven't verified this though.
I'm all for skipping unneeded build load [...] What am I missing here?
Let's assume that we have a patch train with 10 patches and during the review a typo fix in the first patch is requested and all other patches got +2s without any change requests. Until now the solution was to update the first patch and only push the first patch with the typo fix and just leave the following 9 patches at their initial version, so Jenkins won't build those 9 patches again. When re-pushing the full patch train, the other 9 patches will get build tested again after the unnecessary update and again when the patches get submitted. I don't think that this is a huge problem, but still something to think about if we want to change this from what we've done in the recent past.
I reread the documentation and the thing I missed in there is that Gerrit will only automatically rebase a patch when submitting when none of the files it changed have been changed between the parent commit of the to be submitted patch and the current top of tree.
That seems like an improvement to me. By the way, I don't think Gerrit has ever actually rebased anything, nor will it with the new setting, I understand it to always do an equivalent of "git cherry-pick" but with different requirements with the new strategy.
Rebases have always been manual, but before it didn't matter too much, since the cherry-pick strategy just tries to cherry-pick a commit and only requires a manual rebase when there's a git conflict that makes the cherry-pick fail. Now it requires a manual rebase when any of the files the commit changes have been changed in the meantime and not only when there are git conflicts, which happens way more often; especially when there are tree-wide changes or in the case of patch trains where the patches change the same files; see my next answer on the latter.
Hmm, how so? Submitting one commit at a time should make top of tree always match the parent commit of the to-be-submitted commit, right?
That was my assumption, but that turned out to not be the case which was the main reason for my first email today. Gerrit adds some lines to the commit message which will change the git hash; maybe that's part of the reason?
There was a patch train with at least the first few commits being submittable and after i submitted the first patch, Gerrit now shows merge conflicts on all following patches that should still be mergeable which is a dealbreaker for me. If you want to have a look yourself: CB:66272 was the first patch i submitted and now CB:66273 and following suddenly have merge conflicts which they didn't have before.
Regards, Felix