On Mon, Nov 4, 2024 at 9:55 AM Fedor Pchelkin <pchelkin@xxxxxxxxx> wrote: > > On Tue, 29. Oct 18:12, Fedor Pchelkin wrote: > > On Tue, 29. Oct 10:20, Sasha Levin wrote: > > > On Tue, Oct 29, 2024 at 04:31:40PM +0300, Fedor Pchelkin wrote: > > > > BTW, a question to the stable-team: what Git magic (3-way-merge?) let the > > > > duplicate patch be applied successfully? The patch context in stable trees > > > > was different to that moment so should the duplicate have been expected to > > > > fail to be applied? > > > > > > Just plain git... Try it yourself :) > > > > > > $ git checkout 282f0a482ee6 > > > HEAD is now at 282f0a482ee61 drm/amd/display: Skip Recompute DSC Params if no Stream on Link > > > > > > $ git cherry-pick 7c887efda1 > > > > 7c887efda1 is the commit backported to linux-6.1.y. Of course it will apply > > there. > > > > What I mean is that the upstream commit for 7c887efda1 is 8151a6c13111b465dbabe07c19f572f7cbd16fef. > > > > And cherry-picking 8151a6c13111b465dbabe07c19f572f7cbd16fef to linux-6.1.y > > on top of 282f0a482ee6 will not result in duplicating the change, at least > > with my git configuration. > > > > I just don't understand how a duplicating if-statement could be produced in > > result of those cherry-pick'ings and how the content of 7c887efda1 was > > generated. > > > > $ git checkout 282f0a482ee6 > > HEAD is now at 282f0a482ee6 drm/amd/display: Skip Recompute DSC Params if no Stream on Link > > > > $ git cherry-pick 8151a6c13111b465dbabe07c19f572f7cbd16fef > > Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > > HEAD detached at 282f0a482ee6 > > You are currently cherry-picking commit 8151a6c13111. > > (all conflicts fixed: run "git cherry-pick --continue") > > (use "git cherry-pick --skip" to skip this patch) > > (use "git cherry-pick --abort" to cancel the cherry-pick operation) > > The previous cherry-pick is now empty, possibly due to conflict resolution. > > If you wish to commit it anyway, use: > > > > git commit --allow-empty > > > > Otherwise, please use 'git cherry-pick --skip' > > Sasha, > > my concern is that maybe there is some issue with the scripts used for the > preparation of backport patches. > > There are two different upstream commits performing the exact same change: > - 50e376f1fe3bf571d0645ddf48ad37eb58323919 > - 8151a6c13111b465dbabe07c19f572f7cbd16fef There were cases where I needed to cherry-pick fixes from -next to -fixes. In the past I had not used -x when cherry-picking because I got warnings about references to commits that were not yet in mainline. I have since started using -x when cherry-picking things from -next to -fixes. Alex > > 50e376f1fe3bf571d0645ddf48ad37eb58323919 was backported to stable kernels > at first. After that, attempts to backport 8151a6c13111b465dbabe07c19f572f7cbd16fef > to those stables should be expected to fail, no? Git would have complained > about this - the patch was already applied. > > It is just strange that the (exact same) change made by the commits is > duplicated by backporting tools. As it is not the first case where DRM > patches are involved per Greg's statement [1], I wonder if something can be > done on stable-team's side to avoid such odd behavior in future. > > [1]: https://lore.kernel.org/stable/20241007035711.46624-1-jsg@xxxxxxxxx/T/#u > > -- > Thanks, > Fedor
