Stacked PRs are not breaking up a set of commits into divisible units. Like you said, you can already do that yourself. They let you continue to work off of a PR as your new base. This lets you continue to iterate asynchronously to a review of the earlier PRs, and build on top of them.

You often, very often, need to stage your work into reviewer-consumable units. Those units are the stack.

The github UI may change the target to main but your local working branch doesn't, and that's where you `rebase --onto` to fix it, before push to origin.

It's appropriate for github to automatically change the target branch, because you want the diff in the ui to be representative. IIRC gitlab does a much better job of this but this is already achievable.

What is actually useful with natively supported stacks is if you can land the entire stack together and only do 1 CI/actions run. I didn't read the announcement to see if it does that. You typically can't do that even if you merge PR B,C,D first because each merge would normally trigger CI.

EDIT: i see from another comment (apparently from a github person) that the feature does in fact let you land the entire stack and only needs 1 CI run. wunderbar!

2015 - Characterizing ICMP Rate Limitation on Routers[1]

[0] https://pages.cs.wisc.edu/~suman/courses/640/papers/govindan...

[1] https://inria.hal.science/hal-01111190/document

If the theory about framebuffer pre-allocation strategy is to hold any water, I would think that 5k and 6k devices would suffer too, maybe even more. Given that you can attach 2x 5k monitors, the pre-allocation strategy as described would need to account for that.

https://bjango.com/articles/macexternaldisplays/

  - 24" you need 4k
  - 27" you need 5K.
  - 32" you need 6k.

> For the recipient, a fax is a physical reality. It requires paper. It requires ink. It requires time.

Interesting misconception in 2026.

Of course if you read on, it's clear the story is embellished.

that said, you can create multiple users per macOS device, and each can have a different Apple Account. that's a nightmare, because some significant areas of device management assume a single Apple Account. So for example you can use a 2nd account to get around Activation Lock in some cases.

SOC2 reports are private between you and the auditor (that way if you "fail" you can just find another auditor or have a re-do, and no one is the wiser), and basically always gated behind a sales touchpoint (another hint about what utility they provide). I guess the Delve ones leaked which is why they can all be compared.

220 out of 494 "no exceptions" seems quite high to me. Nobody I've ever dealt with allows an exception to make its way into the report.