←back to thread

The GitHub website is slow on Safari

(github.com)
446 points talboren | 1 comments | 27 Aug 25 09:43 UTC | HN request time: 0.255s | source
Show context
muglug ◴[27 Aug 25 13:03 UTC] No.45039093[source]▶
Improvements merged within the last two days by the WebKit team: https://github.com/orgs/community/discussions/170922#discuss...

For my sins I occasionally create large PRs (> 1,000 files) in GitHub, and teammates (who mostly all use Chrome) will sometimes say "I'll approve once it loads for me..."

replies(6): >>45039371 #>>45039546 #>>45039877 #>>45040882 #>>45043276 #>>45050622 #
patrickmay ◴[27 Aug 25 13:26 UTC] No.45039371[source]▶
That seems essentially unreviewable. If you can share without violating an NDA, what kind of PR would involve that many files?
replies(6): >>45039414 #>>45039433 #>>45039455 #>>45039478 #>>45040667 #>>45041353 #
bob1029 ◴[27 Aug 25 13:34 UTC] No.45039478[source]▶
"Upgrade solution from .NET Framework 4.8 => .NET 8"

"Rename 'CustomerEmailAddress' to 'CustomerEmail'"

"Upgrade 3rd party API from v3 to v4"

I genuinely don't get this notion of a "max # of files in a PR". It all comes off to me as post hoc justification of really shitty technology decisions at GitHub.

replies(2): >>45039963 #>>45041641 #
1. bityard ◴[27 Aug 25 16:15 UTC] No.45041641[source]▶
I've always thought those kinds of large-scale search-and-replace diffs should not generally be expected to be reviewed. If a review is 1000's of lines of identical changes (or newly-vendored code), literally nobody is actually reading it, even if they are somehow able to convince themselves that they are.

I would rather just see the steps you ran to generate the diff and review that instead.