Cherry-pick of fd82dbe has failed:

On branch mergify/bp/master/pr-9908
Your branch is up to date with 'origin/master'.

You are currently cherry-picking commit fd82dbe7f.
  (fix conflicts and 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)

Changes to be committed:
	deleted:    changelog.d/issue-9578
	deleted:    changelog.d/pr-9583
	deleted:    changelog.d/pr-9813
	deleted:    changelog.d/pr-spdx

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by them: changelog.d/issue-9736
	deleted by us:   release-notes/Cabal-3.12.0.0.md
	deleted by us:   release-notes/WIP-cabal-install-3.12.x.0.md

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

Was backport the right way to do this? I don't think we want it deleting changelogs for PRs landed in master after 3.12 was branched.

Then we would have duplicate entries in release notes, am I wrong? (e.g. one on Cabal-release-notes-3.12.md and one in Cabal-release-notes-3.14.md)

See last sentence in Making a release “C.2 CHANGELOGs” section.

No, it looks like it wants to delete the changelogs for everything committed to master after 3.12, so we would be missing the changelogs for those.

Never mind, spot checks suggest those are just delayed backports and indeed should be deleted.

I am left wondering how to fix the conflicts, since they're whole-file changes instead of commit markers. Mergify's a bit confusing.

Yes, next time we will do the sensible stuff and produce a changelog after everything is backported.

I am left wondering how to fix the conflicts, since they're whole-file changes instead of commit markers. Mergify's a bit confusing.

Normally, with git, I'd git reset, git add the few files that are not deleted and create a new commit with the old name. Would then pushing -f convince mergify it's resolved? Actually, do we care what mergify thinks? I wouldn't be surprised if it doesn't mind merging commits with conflicts as long as CI passes. In fact, I think, it did in the past causing us grief. :)

Hmm, but that solves only this single failed cherry-pick, which is a part of the big rebase. So I think I'd rather make the whole rebase locally, resolving this conflict and letting rebase continue, and push -f the result to this PR.

And I'd first locally squash the 2 commits in #9908 so that the big rebase is just a single cherry pick of the squashed commit onto the master branch. Makes conflict resolution easier.

Does it make sense?

The culpirit is #9810, which modified changelog files that we already deleted in 3.12. I am going to open a new PR which should simplify this.