[numbsafari]

I'd love it if there was a way for me to queue my comments before submitting. I often keep my comments in a separate textedit/nv window and then go back to put them in since I want to keep track of questions that arise as I'm reading, but I don't want to pepper someone with comments that would be resolved 200 lines later in the diff.

[Hovertruck]

Yeah this is my #1 feature request, and the main reason that a number of companies I've worked for/chatted with have switched to using Phabricator for their code review.

[BinaryIdiot]

As you enter your comments just don't click the "comment" button. Github saves the text anyway as you go. I don't know how long it takes to save the text (so maybe don't refresh or leave the instant you finish writing a comment) but in general they should all be there. Then you just have to scroll through and click comment on each one.

Certainly not as easy as seeing them in a nice row for review but it's a workaround at least.

[mfonda]

This is my biggest feature request here as well. I'll often write a lot of small comments inline in the diff, and a bigger comment on the PR itself tying everything together. It'd be nice to be able to submit it all at once, with the ability to reference inline comments in my main comment.

[jawns]

Can't you just enter your comment into the text box but not hit the "Comment" button until you've gotten through the whole PR? I just gave it a shot, and it looks like you can have multiple comment text boxes open simultaneously.

[bpicolo]

And yet it will still send <n> emails at the end, and you lose progress if you close tab

[piotrkaminski]

Reviewable (https://reviewable.io) is built around this workflow: it will keep your drafts, let you review them, then send them all at once (triggering a single notification email).

Disclosure: I built the tool. :)

[Perceptes]

This is what I was expecting this announcement to be. It's the most often requested change for GitHub Issues that I've seen. I hope they follow up with this soon.

[vikiomega9]

Are 200 line diff common? I feel like having focused patches are useful for everyone. Including git bisect and CI/CD.

[oinksoft]

The line count of a diff has nothing to do with how focused the patch is. Some PRs are simply larger than others due to the language in use or the nature of the code being changed.

Presumably a codebase in an array-oriented language would have miniscule PRs, which is irrelevant (discussion of PL merits aside).

[majewsky]

Totally. Just click "rails generate" twice. ;)

[dromtrund]

I read it as a separate diff 200 lines later. But I guess pull requests could easily have that big diffs in a public repo