On Fri, Jan 17, 2025 at 12:01:01PM +0100, Uwe Kleine-König wrote: > On Sun, Jan 12, 2025 at 10:06:42PM +0100, Greg KH wrote: > > That's fine, the issue is that you are the only ones with "duplicate" > > commits in the tree that are both tagged for stable, every release. > > Isn't a solution as easy as teaching your tooling not to create/accept > commits on -next with Cc: stable? This way folks intending to push a > change will notice it should go to the fixes branch. And if only > afterwards you notice this is a critical fix that should get backported > at least the commit that takes more time entering mainline doesn't have > the stable tag. > > Maybe additionally make sure that Fixes: and revert notices only point > to commits that are an ancestor. The commit is always an ancestor, the "trick" is which one when the ancestor was cherry-picked previously? That's the real problem here.. gre k-h
