5 ms·

All everything aside, reviewing big pull requests on GitHub became nearly impossible - even with the simplest change view it makes you spend too much time on wa

by xvilka 8mo ago

All everything aside, reviewing big pull requests on GitHub became nearly impossible - even with the simplest change view it makes you spend too much time on waiting for the page to load the necessary file first. The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded.

arccy 8mo ago
They even have the gall to call it an improved UI for reviewing large pull requests. They must have let UI designers who've never written code before design it.
- shimman 8mo ago
  IME those types of UI designers are way way way way more common, very few designers seem to understand the platform they are designing on and care more about aesthetics rather than proper platform designs.
- bflesch 8mo ago
  That's what happens when the whole company uses high-end macbooks and nobody has an older PC. It's been noted thousands of times on HN but these US companies make money head over fist and do not give a single damn about people on "lower" end devices.
  - plorkyeran 8mo ago
    Large GitHub PRs are miserably slow even with a maxed out Mac Studio on gigabit fiber with single-digit ms ping to their server. It’s not an example of something that works well on high-end hardware but scales down poorly.
bjackman 8mo ago
Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used GitHub and Gitlab which both seem like toys to me. (And mailing lists, lol). But the implementation of Gerrit seems rather unloved, it just seems to get the minimal maintenance to keep Go/Android chooching along, and nothing more.
- seabrookmx 8mo ago
  My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default. Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.
  - bjackman 8mo ago
    You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
    - techcode 8mo ago
      What do you mean by "stack" MRs? Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master. Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
      - bjackman 8mo ago
        I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history. This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff. If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
        seabrookmx 8mo ago
viraptor 8mo ago
While I'm not annoyed by the slowdown that much, what made me not trust them anymore is being careless with the system. For example I did a review recently on a PR where the collapsing sections were not visible and made 2 patch fragments look like continuous code. I commented that this makes no sense and won't run... only to look like an idiot later. Fortunately the issue was fixed by the time I looked at the PR again, but still, much less trust now.
razighter777 8mo ago
Quick tip: If you type .patch after the PR url it gives you a git patch. Do curl <github patch> | git am and you can apply and review it locally.
- IshKebab 8mo ago
  No need for that. Just install the VSCode GitHub extension and you can just directly open them. It even supports comments. Hell even if you don't use VSCode there are much better options than messing around with patch files.
  - SahAssar 8mo ago
    When I read > No need for that. I generally expect a less complex solution, it seems like your is more complex (easiness is arguable though)
  - klardotsh 8mo ago
    VSCode is not a “given” - I certainly don’t use, or ever intend to use, it. Patch files are excellent for small diffs at a glance. Sure, I can also `git remote add coworker ssh://fork.url` and `git diff origin/main..coworker/branch`, and that would even let me use Difftastic (!), but the patch is entirely reasonable for quick glances of small branch diffs.
ahartmetz 8mo ago
Heck, you can't - to the best of my knowledge - even comment on changes in a commit instead of just the sum total of changes in a pull request. It's as if GitHub expects everyone to use squash on merge workflows, which is insane for developers who know how to structure commits and write commit messages. Oh yeah, and you can't comment on commit messages neither. In Gerrit (which otherwise has plenty of problems, too), they show up as part of the patch.
- toastal 8mo ago
  Most developers haven’t seemed to use another workflow unfortunately—& they scoff at suggesting the only workflow they know could be wrong.
- jamietanna 8mo ago
  In the "files changed" view on GitHub you can view the PR commit-by-commit and comment on that commit's change
hulitu 8mo ago
> The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded. Just like Microsoft Windows. I wonder if they are the same company. /s

by xvilka 8mo ago

arccy 8mo ago

They even have the gall to call it an improved UI for reviewing large pull requests. They must have let UI designers who've never written code before design it.

shimman 8mo ago
IME those types of UI designers are way way way way more common, very few designers seem to understand the platform they are designing on and care more about aesthetics rather than proper platform designs.
bflesch 8mo ago
That's what happens when the whole company uses high-end macbooks and nobody has an older PC. It's been noted thousands of times on HN but these US companies make money head over fist and do not give a single damn about people on "lower" end devices.
- plorkyeran 8mo ago
  Large GitHub PRs are miserably slow even with a maxed out Mac Studio on gigabit fiber with single-digit ms ping to their server. It’s not an example of something that works well on high-end hardware but scales down poorly.

bjackman 8mo ago

Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used GitHub and Gitlab which both seem like toys to me. (And mailing lists, lol). But the implementation of Gerrit seems rather unloved, it just seems to get the minimal maintenance to keep Go/Android chooching along, and nothing more.

seabrookmx 8mo ago
My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default. Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.
- bjackman 8mo ago
  You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
  - techcode 8mo ago
    What do you mean by "stack" MRs? Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master. Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
    - bjackman 8mo ago
      I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history. This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff. If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
      - seabrookmx 8mo ago

viraptor 8mo ago

While I'm not annoyed by the slowdown that much, what made me not trust them anymore is being careless with the system. For example I did a review recently on a PR where the collapsing sections were not visible and made 2 patch fragments look like continuous code. I commented that this makes no sense and won't run... only to look like an idiot later. Fortunately the issue was fixed by the time I looked at the PR again, but still, much less trust now.

razighter777 8mo ago

Quick tip: If you type .patch after the PR url it gives you a git patch. Do curl <github patch> | git am and you can apply and review it locally.

IshKebab 8mo ago
No need for that. Just install the VSCode GitHub extension and you can just directly open them. It even supports comments. Hell even if you don't use VSCode there are much better options than messing around with patch files.
- SahAssar 8mo ago
  When I read > No need for that. I generally expect a less complex solution, it seems like your is more complex (easiness is arguable though)
- klardotsh 8mo ago
  VSCode is not a “given” - I certainly don’t use, or ever intend to use, it. Patch files are excellent for small diffs at a glance. Sure, I can also `git remote add coworker ssh://fork.url` and `git diff origin/main..coworker/branch`, and that would even let me use Difftastic (!), but the patch is entirely reasonable for quick glances of small branch diffs.

ahartmetz 8mo ago

Heck, you can't - to the best of my knowledge - even comment on changes in a commit instead of just the sum total of changes in a pull request. It's as if GitHub expects everyone to use squash on merge workflows, which is insane for developers who know how to structure commits and write commit messages. Oh yeah, and you can't comment on commit messages neither. In Gerrit (which otherwise has plenty of problems, too), they show up as part of the patch.

toastal 8mo ago
Most developers haven’t seemed to use another workflow unfortunately—& they scoff at suggesting the only workflow they know could be wrong.
jamietanna 8mo ago
In the "files changed" view on GitHub you can view the PR commit-by-commit and comment on that commit's change

hulitu 8mo ago

> The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded. Just like Microsoft Windows. I wonder if they are the same company. /s