Hi Peter,
I definitely want to submit a patch train patch by patch and not just the last submittable patches including all patches before to make sure that I looked at each individual patch when submitting.
Maybe the patch train is too long if it becomes hard to keep an overview?
I'd say that it always better to have to look at all the individual patches instead of just looking at the bigger picture like it's usually done in the Github workflow that is focused on whole branches instead of the individual patches. This is also why I strongly prefer the Gerrit workflow that focuses on individual patches.
When part of a patch train gets re-pushed due to some small fixes that won't affect patches after a certain patch and then all patches from the patch series are reviewed and submittable, how will the case that later patches are on top of outdated patches be handled?
Hmm, I don't understand what you mean here..
If you have pushed a branch with 3 commits, use interactive rebase locally to fix up the middle commit and then push the branch again, doesn't Gerrit always recognize that the first commit remains unchanged, ie. with one generation less than the middle and last commit?
To reduce unnecessary load on the build servers, it has become common practice to only push up to the changed patch and not the patches after that if the changes if the fixes are unrelated and there's more than maybe one patch after the one being updated. This is for example the case when fixing a typo in a commit message or comment in some commit that isn't right at the end of a patch train.
If the patches aren't actually linked (ie. can be submitted individually) then I think they shouldn't be pushed as a single branch, right?
Yes, but that's not the case I tried to outline; I hope that the text above makes it a bit more clear which case I was thinking of here.
Regards, Felix