"Tests / Change detection / Create context from changed files" fails with:

+ git fetch origin +f27896c3191c5ffd85a62ac89a98f72fb14d9c61:remotes/origin/3.14 '--shallow-since=2026-02-05 12:04:04 +0100' --no-tags --prune --no-recurse-submodules
fatal: error processing shallow info: 4

I don't know why.

Maybe a GH outage, it sets github.event.pull_request.commits: 0 causing the error. I suggest trying to re-run in a bit.

I hope you don't mind if I ask :)
You did simpler version of 3.13 and 3.14 because #144469 changes user-observable behavior and that change considered as a feature?

I tried it again, still github.event.pull_request.commits is 0. Maybe the have some internal corruption, @webknjaz have you seen this before? I'll try updating the branch, that'll (theoretically) change the number and jog the data.

Edit: that worked, though I still wonder why it occurred in the first place... GitHub doing its thing 🙃

You did simpler version of 3.13 and 3.14 because #144469 changes user-observable behavior and that change considered as a feature?

Correct. The change ffa6852 introduces behavior changes, such as:

PyClassMethod_New() and PyStaticMethod_New() now copy attributes of
the wrapped functions: __module__, __name__, __qualname__ and
__doc__.

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

GH-144537 is a backport of this pull request to the 3.13 branch.

@vstinner Thanks!

Edit: that worked, though I still wonder why it occurred in the first place... GitHub doing its thing 🙃

@StanFromIreland GH updates the ephemeral PR merge pointer on certain events (like pushing a new commit). When there's outages, these events aren't delivered to the respective components, which may cause PR state to go out of sync. Once the outage is over, pushing again should generally fix it, but on a rare occasion GH's internal state is so broken that nothing can salvage it — in such cases the only solution would be creating a new PR.