Most active commenters

    ←back to thread

    The GitHub website is slow on Safari

    (github.com)
    446 points talboren | 12 comments | 27 Aug 25 09:43 UTC | HN request time: 0.001s | source | bottom
    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. ambicapter ◴[27 Aug 25 14:09 UTC] 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 #
    2. eviks ◴[27 Aug 25 14:34 UTC] No.45040291[source]▶
    How much working memory/attention span is required to look through 1000 identical lines "-CustomerEmailAddress +CustomerEmail"?
    replies(1): >>45040910 #
    3. shadowgovt ◴[27 Aug 25 15:19 UTC] No.45040910[source]▶
    Ideally, you automate a check like that. Because the answer turns out to actually be "humans are profoundly bad at that kind of pattern recognition."

    A computer will be able to tell that the 497th has a misspelled `CusomerEmail` or that change 829 is a regexp failure that trimmed the boolean "CustomerEmailAddressed" to "CustomerEmailed" with 100% reliability; humans, not so much.

    replies(3): >>45041140 #>>45041171 #>>45047557 #
    4. sidewndr46 ◴[27 Aug 25 15:31 UTC] 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

    5. makeitdouble ◴[27 Aug 25 15:35 UTC] No.45041140{3}[source]▶
    You're not just reviewing the individual lines, but also which context, and which files are impacted. And automating that part would still mean reviewing the automation and the 1000+ changes to move to it.

    Sure 1000+ changes kills the soul, we're not good at that, but sometimes there's just no other decent choice.

    6. eviks ◴[27 Aug 25 15:38 UTC] No.45041171{3}[source]▶
    Oh, certainly, didn't mean that you had to avoid using your IDE to autorename a variable yourself (to avoid the boolean issue) and diffed results to those of the PR

    Or that you had to avoid Ctrl+F "CustomerEmail" and see whether you had 1000 matches that matches the number of changed files or only 999 due to some typo.

    Or using the web interface to filter by file type to batch your reviews.

    Or...

    Just that in none of those cases there is anything close to our memory/attention capacity.

    replies(2): >>45041585 #>>45042397 #
    7. ◴[27 Aug 25 16:10 UTC] No.45041585{4}[source]▶
    8. shadowgovt ◴[27 Aug 25 17:21 UTC] No.45042397{4}[source]▶
    I envy your IDE being able to do a rename of that scale.

    I work in a large C++ codebase and a rename like that will actually just crash my vscode instance straight-up.

    (There are good automated tools that make it straightforward to script up a repository-wide mutation like this however. But they still generate PRs that require human review; in the case of the one I used, it'd break the PR up into tranches of 50-ish files per tranche and then hunt down individuals with authority to review the root directory of the tranche and assign it to them. Quite useful!)

    replies(1): >>45043353 #
    9. trenchpilgrim ◴[27 Aug 25 18:39 UTC] No.45043353{5}[source]▶
    Yeah VSCode is pretty terrible at refactorings that Jetbrains or Zed will do basically instantly.
    10. const_cast ◴[28 Aug 25 02:10 UTC] No.45047557{3}[source]▶
    We already automate that, it's called a compiler. The human review is just for kicks for this type of thing.

    Of course some languages... PHP... aren't so lucky. $customer->cusomerEmail? Good luck dealing with that critical in production, fuckheads!

    replies(1): >>45051422 #
    11. muglug ◴[28 Aug 25 12:38 UTC] No.45051422{4}[source]▶
    What if I told you there were tools for that
    replies(1): >>45068742 #
    12. const_cast ◴[29 Aug 25 20:01 UTC] No.45068742{5}[source]▶
    I'm aware of the tools, I write PHP daily.

    The point is moreso that PHP won't stop you from doing that. It will run, and it will continue running, and then it will throw an error at some point. Maybe.

    If the code is actually executed. If it's in a branch that's only executed like 1/1000 times... not good.