Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I miss this functionality when reviewing large Github PR's.

A PR can quickly contain thousands of changed (added/removed) lines of code. When reviewing a PR, I want to keep track of which lines I've already approved. I would love to see a way to mark code blocks or entire commits as "reviewed". This is especially handy because PR diff's are shown alphabetically by file path, but the code paths obviously aren't, so it's really hard to keep track of review progress.



In GitLab you can't exactly do as you suggest, but you can collapse a diff, the state of which is kept. You could use that.

I'd love for you to add some more flavor here [0], so we can see if we can build something like that.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/19049#note_15...


Why are you allowing such large pulls?

Everyone who complains about githubs pull request UI always has the same root cause, huge, long lived reviews.

Don't fix bad process with more process and tooling. Fix it at the root.


Because the feature is large? Or the developer acted normally and split thing into multiple, small, independant commits?

If the submittor then takes a lot of time between comments and performing changes, is the commentor to blame for a PR being long-lived?

Don't assume everything is bad process.


Why can't it be a series of small PRs then? Or do you not do continuous delivery?


Because then the reviews for the connected PRs ends up being hideous to track.

Either you can:

• Submit the PRs one at a time... which is awful. Why not work on them in parallel?

• Submit your series of PRs all at once, then you have to set the PR base of each one to the following one to make the github diff view actually reasonable for reviews. THEN, when you have a code change based on feedback on the first PR, you have to merge it into all the later dependent PRs. THEN, you have to have to jiggle the PR bases very carefully when you're landing the PRs, otherwise it will merge them all into each other, and you end up with one ginormous commit landing—defeating the point of the small commits. AND unless you're using a squash based workflow, you'll end up with that giant merge mess in the middle of your commit history.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: