Live data from Hacker News

Pull Request File Tree Feedback

github.com

41–50 of 77 posts

Re: Pull Request File Tree Feedback

#41

Funny but Azure Repos actually has had this feature for a while. When I first joined Microsoft I was shocked that all our teams used Azure Repos instead of GitHub considering we own GitHub but as I've used Repos more and more I've actually come to like it more than GitHub itself. A lot of the UI is cleaner and more intuitive than GitHub to me now, maybe just from using it a lot.

+1. I had the same experience joining Microsoft. I wasn't super thrilled by Azure at first, but was surprised by how much functionality it had. Fast forward a couple years later, I moved to another big tech company using Github instead, which had setup integrations with a bunch of different external tools (and this one was no slouch when it comes to engineering tooling). I can't tell you how much I missed Azure, even though I've had my issues with MSFT.

Re: Pull Request File Tree Feedback

#42
post #38

Earlier quoted context omitted.

Might be worth making a bounty for it in refined github[0], similar things have been implemented in the past[1] [0] https://github.com/refined-github/refined-github [1] https://github.com/refined-github/refined-github/issues/2151

An extension shouldn't be needed for a dev-centric service like GH to be usable. This is the wrong way to fight bad UX, as it's ridiculous to make installation of a potential security vulnerability of an addon necessary to make a git-frontend website work well. Better to just find a dev-first platform instead.

Seriously. If they’re too busy making sketchy copyright decisions with their AI code generation to bother with basic usable UI, they don’t deserve to be the de facto home of open source. I’ve been giving sourcehut a try, and the simplicity is refreshing.

Re: Pull Request File Tree Feedback

#43
post #38

Earlier quoted context omitted.

An extension shouldn't be needed for a dev-centric service like GH to be usable. This is the wrong way to fight bad UX, as it's ridiculous to make installation of a potential security vulnerability of an addon necessary to make a git-frontend website work well. Better to just find a dev-first platform instead.

Seriously. If they’re too busy making sketchy copyright decisions with their AI code generation to bother with basic usable UI, they don’t deserve to be the de facto home of open source. I’ve been giving sourcehut a try, and the simplicity is refreshing.

There's no denying the appeal of underdogs like SirHat :)

Re: Pull Request File Tree Feedback

#44

I’d settle for them making PRs as useful as they were in 2015, before they messed up some of the most basic functionality: showing the diff, and showing review comments. They hide big diffs behind a “load more” link, and as a result people often fail to code review the most substantial part of a change because they scan right past it, thinking it’s a removed file or binary or something. Then, once you submit a review…

Maybe they're trying to nudge us towards smaller PRs. Many reviewers gloss over 300+ line changes in a single file. Approved with a "LGTM" and no further comment, but perhaps that's more a cultural issue with the team than anything.

This sounds like I’m “holding my phone wrong.”

Re: Pull Request File Tree Feedback

#45

I’d settle for them making PRs as useful as they were in 2015, before they messed up some of the most basic functionality: showing the diff, and showing review comments. They hide big diffs behind a “load more” link, and as a result people often fail to code review the most substantial part of a change because they scan right past it, thinking it’s a removed file or binary or something. Then, once you submit a review…

Additionally, the notification email links to "View it on GitHub" don't reliably cause the relevant parts of the page to expand so you end up wading through a huge PR expanding things at random until you find the message.

Exactly. Once they turned the page into JS framework soup instead of regular HTML, the anchor links don’t work worth a damn.

Re: Pull Request File Tree Feedback

#46
Hi! I am one of the authors of https://graphite.dev, we are basically a really fancy client to GH that lets you review others PRs without making them change their workflow at all (posts everything to GH etc)

We've had a file tree for some time now (along with some of the other feedback I'm seeing in this thread, large diffs etc).

If anyone wants to give it a spin, happy to give you an invite :)

Re: Pull Request File Tree Feedback

#47
post #38

Earlier quoted context omitted.

Might be worth making a bounty for it in refined github[0], similar things have been implemented in the past[1] [0] https://github.com/refined-github/refined-github [1] https://github.com/refined-github/refined-github/issues/2151

An extension shouldn't be needed for a dev-centric service like GH to be usable. This is the wrong way to fight bad UX, as it's ridiculous to make installation of a potential security vulnerability of an addon necessary to make a git-frontend website work well. Better to just find a dev-first platform instead.

Perhaps you are more fortunate than me, but in my career, there have been times where I couldn't dictate the platform used. This is actually the case for many people - I daresay the majority - who work in the software industry. So while I understand (and of course agree with) the sentiment, it's rather trite. Plugins are there for the rest of us.

Re: Pull Request File Tree Feedback

#48
post #9

One of the few things worth actually stealing from BitBucket. Lol

Since GitHub is owned by Microsoft and their other product has had this, I’m guessing it’s yet another copy-over like GitHub Actions was from Azure Pipelines. Not sure how long it’s been in AzureDevOps but it could have been inspired from GitLab there I suppose.

ADO will go away once all of the features are migrated to GitHub.

Re: Pull Request File Tree Feedback

#49

I’d settle for them making PRs as useful as they were in 2015, before they messed up some of the most basic functionality: showing the diff, and showing review comments. They hide big diffs behind a “load more” link, and as a result people often fail to code review the most substantial part of a change because they scan right past it, thinking it’s a removed file or binary or something. Then, once you submit a review…

Maybe they're trying to nudge us towards smaller PRs. Many reviewers gloss over 300+ line changes in a single file. Approved with a "LGTM" and no further comment, but perhaps that's more a cultural issue with the team than anything.

> Maybe they're trying to nudge us towards smaller PRs. Many reviewers gloss over 300+ line changes in a single file.

Unfortunately there are a massive number of codebases where a "simple" change can mean changing _lots_ of places.

Post reply on HN