RE: Stacked Diffs on @GitHub
After discussion w @ttaylorr_b, we can implement stacked PRs/PR groups already (in fact we kind of do with Copilot) but restacking (automatically fanning out changes from the bottom of the the stack upwards) would be wildly inefficient. To do it right, we need to migrate @GitHub to use git reftables instead of packed-refs so that multi-ref updates / restacking will be O(n) instead of ngmi.
This will take some time but has been greenlit.
After discussion w @ttaylorr_b, we can implement stacked PRs/PR groups already (in fact we kind of do with Copilot) but restacking (automatically fanning out changes from the bottom of the the stack upwards) would be wildly inefficient. To do it right, we need to migrate @GitHub to use git reftables instead of packed-refs so that multi-ref updates / restacking will be O(n) instead of ngmi.
This will take some time but has been greenlit.
To be clear, packed-refs doesn't make restacking impossible by itself, and we already can/do batch reference updates together into a single transaction. Any individual transaction only rewrites the packed-refs file at most once.
The thing that @ttaylorr_b et al is more worried about is having many more references in general as a result of stacked PRs (e.g., refs/pull/NNN/v1, refs/pull/NNN/upstack, etc.) and the slowdown that would cause when doing deletions (outside of stacked PRs) in general.
The thing that @ttaylorr_b et al is more worried about is having many more references in general as a result of stacked PRs (e.g., refs/pull/NNN/v1, refs/pull/NNN/upstack, etc.) and the slowdown that would cause when doing deletions (outside of stacked PRs) in general.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
