On 19/04/2023 10:16, Deucher, Alexander wrote: > [...] >> This is quite strange for me, we have 2 commit hashes pointing to the >> *same* commit, and each one is present..in a different release !!?! >> Since I've marked this patch as fixing 82132ecc5432 originally, 6.1.y stable >> misses it, since it only contains 9a8cc8cabc1e (which is the same patch!). >> >> Alex, do you have an idea why sometimes commits from the AMD tree >> appear duplicate in mainline? Specially in different releases, this could cause >> some confusion I guess. > > This is pretty common in the drm. The problem is there is not a good way to get bug fixes into both -next and -fixes without constant back merges. So the patches end up in -next and if they are important for stable, they go to -fixes too. We don't want -next to be broken, but we can't wait until the next kernel cycle to get the bug fixes into the current kernel and stable. I don't know of a good way to make this smoother. > > Alex Thanks Alex, seems quite complicated indeed. So, let me check if I understood properly: there are 2 trees (-fixes and -next), and the problem is that their merge onto mainline happens apart and there are kind of duplicate commits, that were first merged on -fixes, then "re-merged" on -next, right? Would be possible to clean the -next tree right before the merge, using some script to find commits there that are going to be merged but are already present? Then you'd have a -next-to-merge tree that is clean and doesn't present dups, avoiding this. Disclaimer: I'm not a maintainer, maybe there are smart ways of doing that or perhaps my suggestion is silly and unfeasible heh But seems likely that other maintainers face this problem as well and came up with some solution - avoiding the dups would be a good thing, IMO, if possible. Cheers, Guilherme
