I don't share the worry. This point is the same as in the current staging-* pull requests, isn't it?

@vcunat It should be fine, I agree. I had some problems with the current PR, but maybe that was mostly cases of the base reference not updating when staging was pushed when haskell-updates was already ahead which should never happen with this.

I've tested this on my fork (by removing the if).

• Successful run: https://github.com/sternenseemann/nixpkgs/actions/runs/12480537165/job/34831522582
• Created merge commit: sternenseemann@a5e5cf0

Unfortunately, the workflow is pretty slow since it has to do a full fetch of nixpkgs. I don't think we can get the merge base via the GitHub API, unfortunately.

We had lots of merge conflicts in this staging-next iteration. And even without them I'm not sure about the order of processing in these automatic merges.

Successful run with the latest version of the PR: https://github.com/sternenseemann/nixpkgs/actions/runs/12505278130/job/34888392237

Solved merge conflicts, run successful: https://github.com/sternenseemann/nixpkgs/actions/runs/12583297518/job/35070543436

Periodic merge from 8f3e1f807051e32d8c95cd12b9b421623850a34d into haskell-updates has failed.

Seems like my fear were warranted. The workflow merged e554bf1 into haskell-updates which is an ancestor of staging at the time of the merge (eb439c0). Despite that, the GitHub UI adds a ton of commits to the PR view (#371032, edit: I've since reset the UI so it may no longer be visible, but will surely happen again).

I know that you can fix this by opening the base branch dropdown menu and selecting the same target branch again. I must say I don't really understand why this is a problem in this situation, but wasn't a problem when we'd target master and merge the current HEAD of master into haskell-updates. Why does GitHub update the head of the base branch for the comparison in one case, but not in the other?

The only difference between the two situations I've outlined above I could think of is that the merge commit merging haskell-updates into master would be part of the branch going forward (or at least as soon as master would be merged into haskell-updates again). With the current situation this only happens after the merge commit goes from staging to staging-next to master and via the merge workflows to staging-next and then to staging, so it is part of the merge-base of haskell-updates and staging.

This definitely causes that the branch always shows up as conflicting with staging since staging is always ahead by the merge conflict that also touches all the files haskell-updates does. This is not a problem in practice, you just have to merge manually and git will be able to solve all “conflicts” automatically.

It seems like the likeliest explanation for the UI glitch on GitHub, but I'm also not quite sure. That you can get the UI out of this bad state shows that it doesn't have to be this way. It is hard to know what GitHub caches internally to cause this problem…