Em Thu, 26 Sep 2024 13:24:48 +0300 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu: > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote: > > Em Thu, 26 Sep 2024 09:30:34 +0000 > > Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> escreveu: > > > > Yet, even if the committer did an honest handling of the patch, you may > > still disagree or want some changes at the original patch. On such cases, > > the maintainers may decide to drop the changes and do a normal review > > process. They may otherwise request a patch on the top of the applied > > one to address the pointed issues. > > Let's do a revert in that case, and keep rebases for cases where having > content in the git history causes issues other than bisection problems. Rebasing or not is a subsystem maintainers decision. Reverting pollutes git history upstream, and it should be done in cases were we want to preserve the history upstream. On cases where the preserving the history doesn't matter, a rebase is better. There is also a bad side effect of doing: - patch 1: some fixes with c/c stable + fixes tag - patch 2: revert patch 1 - patch 3: apply patch 1 on a different way Even with just 3 patches, this can get messy when backporting to fixes, as we don't want all three patches backported. We want just patch 3. There are also cases like: - patch 1: some fixes with c/c stable + fixes tag - patch 2: revert patch 1 - patch 3: a patch needed by patch 1 to not break compilation - patch 4: re-apply patch 1 in this case, patch 3 (or a variant of it) may or may not needed to be in fixes. This becomes even more complex if there is a pile of patches with some with c/c stable and some without. I saw already enough badly solved merge conflicts risen on different trees because one change was reverted and then applied back with about the same content. Thanks, Mauro
