Hi Peter!
Hmm, I'm not sure about that? I understand the effective difference with the new strategy to merely be that a later commit in a pushed changeset/branch can't be submitted before an earlier one.
That is my understanding of this too. What I wanted to point out in my last email is that switching form cherry-pick to always rebase will only catch a small part of the things that resulted in a broken tree in the last year or two. The majority of tree breakages was caused by two independent patches doing something that won't result in a git conflict, but in compile failures. For example when some devicetree register name was changed in the chip.h file and all devicetrees that were in tree at the time and in a separate patch a new mainboard was introduced, but that mainboard was only build-tested on top of the tree before the devicetree change was submitted. Submitting both the board and the devicetree change won't cause a git conflict, but compiling the board will fail causing the tree to be broken. Since this is usually a quick fix that can be submitted via the fast patch with 3x +2, it's not too bad IMHO.
Cherry-pick is useful for longer patch trains where the earlier parts are independent, but some later part needs all the earlier parts. In that case some parts that are independent from the patches before them and are already reviewed and ready to be submitted would need to wait until the patches before them are submittable too. And yes, submitting patches out of order has already resulted in a broken tree in a very small percentage of cases, but most of the time it was also easy to fix.
The main advantage of the always rebase strategy is that with the currently used cherry-pick approach Gerrit shows a merge conflict on later patches in a patch train that depend on some earlier change until the previous patches are submitted, which is a bit confusing when you're not aware that this isn't some error to worry about. The always rebase strategy doesn't have this oddity.
I think each commit is still build tested and verified?
Not right before it gets submitted. It still gets build-tested like before when the patch is pushed to Gerrit and after it got submitted.
And different pushed changesets continue to be build tested individually and can be submitted individually - right?
Correct.
I'm sure the change could be rolled back quickly in case there's any kind of annoying disaster problem in the repo.
I don't expect the always rebase submit strategy to cause any major problem. Regards, Felix _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
