←back to thread

446 points talboren | 1 comments | | HN request time: 0.245s | source
Show context
muglug ◴[] 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 ◴[] 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 ◴[] 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 #
ambicapter ◴[] No.45039963[source]
It's not GitHub-specific advice, it's about reviewability of the PR vs. human working memory/maximum attention span.
replies(2): >>45040291 #>>45041083 #
1. sidewndr46 ◴[] No.45041083[source]
I pretty frequently have conversations with other engineers where I point out that a piece of code makes an assumption that mostly holds true, but doesn't always hold true. Hence, a user visible bug.

The usual response is something like "if you're correct, wouldn't that mean there are hundreds of cases where this needs to be fixed to resolve this bug?". The answer obviously being yes. Incoming 100+ file PR to resolve this issue. I have no other ideas for how someone is supposed to resolve an issue in this scenario