Technically, if the commit was never built, releng could do this.

But I think it's easier to merge the three branches via a merge commit and push that to all three of them. That way, no policy exception is needed. It is a bit uglier, but we have much uglier stuff in git than that. Would that work for you?

I agree with @churchyard here. If you need help with doing this, I can volunteer to assist you.

Technically, if the commit was never built, releng could do this.

Looks like the commit was never built - https://koji.fedoraproject.org/koji/packageinfo?packageID=27782 - none of the f34 or f33 builds have the problematic commit

But I think it's easier to merge the three branches via a merge commit and push that to all three of them. That way, no policy exception is needed. It is a bit uglier, but we have much uglier stuff in git than that. Would that work for you?

I would rather not have a merge commit - will complicate centos stream and rhel

@rmeggins CentOS Stream 9 and RHEL 9 are not inheriting automatically from Fedora at this point, so I am not sure why the contents of F33 or F34 branches matters there?

@rmeggins CentOS Stream 9 and RHEL 9 are not inheriting automatically from Fedora at this point, so I am not sure why the contents of F33 or F34 branches matters there?

true - I guess for centos and rhel we can merge from rawhide branch - still, would prefer not to have merge commit unless there is no other way

I'd pretty much like to avoid force pushes to "official" branches if it doesn't solve a really nasty issue for everybody (e.g. something like this) or if there is no legal requirement to do so. So if this is a request for exception, consider me -1.

I can help with the merge if you want me to.

unless there is no other way

There is another way. Cherry pick to f33 and f34 and never merge them with rawhide again.

The team agreed to merge rawhide to f34 and f33, then on rawhide branch do git merge f34 f33 - now they all point to the same commit, and ff merge will work for subsequent changes