Pull request feature requests

github_requests.md

Hello Github,

Pull requests are not serving me well on large reviews. Here are some problems and suggested enhancements that would make me happy.

• Mark comment as "resolved" (see google docs for an example). As code changes, comments get lost or made redundant, and it is not clear (to either the author or reviewers) which are still relevant and which have been addressed. Resolving a comment doesn't need to make it dissappear, but I need to be able to see "which comments have not been addressed" somehow. This feature would be the most useful to me.
• Reply to a comment. This can be done in effect on line comments (assuming there is only one), but cannot on PR comments. Particularly with many threads, the lack of this makes a review hard to follow.
• Explicit "approve/block" life cycle. The block is actually more important to me ... often on a PR that has been incrementally improved I want to "block" final merge of it until I get a chance to rebase/squash and generally pretty it up. The block can be overridable, I just want a warning when you try to merge that "this will make XXX really sad". I had a heap of disgusting WIP commits merged to repo the other day by someone else that I will forever be embarrased by.
• Incremental diffs. What changed since the last time I reviewed this? A quick way to change the base of the "files changed" diff would be great. Bonus points if I can force push my branch and you track the different shas and I can compare them. I do double-PRs to work around this which is not really cool.

Example large pull requests:

• rspec/rspec-core#1267
• rspec/rspec-mocks#543
• rspec/rspec-mocks#378
• rspec/rspec-mocks#424

I'm happy to provide more detail or talk with someone on the phone if it would assist.

Thanks, Xavier

Personally, I would just love to have a collapsed view of changed files, with a full diff visible only when one clicks on the file name in the list. With large PRs, especially with many removed files which don't need much reviewing, it can get pretty tedious finding the files that have relevant changes to review.

In general, it would be pretty slick to have more of Crucible features in GitHub PRs.

+1 as marking comments as resolved

+1 for marking comments as resolved. This would be incredibly useful. It's the only major feature missing from GitHub as a code review platform.

+1 For being able to mark comments as resolved. This is the biggest pain point for me, and affects nearly every PR. Frequently comments are resolved with "no change needed" or a code change elsewhere, and then they just perpetually clutter up the view making it harder to find only the comments that are not resolved issues.

Yet another 👍 for "resolve comments." Sometimes it's nice for a PR comment to callout good code that shouldn't change. At the same time, it's nice to use comments as a to-do list... so those "nice job!" comments (though nice as they are) linger.

+1 on the ability to resolve comments. Sometimes the comment will get resolved in a different location than the original comment was made in. Sometimes the resolution is to do nothing. In any case, "unresolved" comments are really important to understand on large PRs, otherwise PRs can (and do) get merged prematurely.

+1 for a "resolve comment" feature and to view a list of unresolved comments.

+1 for "resolve comment".

👍 for "resolve comment"

👍 resolving comments!

Have you hear about Gerrit? It is standalone Git hosting and code review solution. There is also GerritHub, a service that provides Gerrit integration with GitHub pull requests,

Here is how the issues you pointed out look like in Gerrit

• Mark comment as "resolved" - there is possibility to replay "Done" to any comment, but there is no possibility to see "which comments have not been addressed", btw I saw that in Atlassian Stash and Upsource, nice feature
• Reply to a comment. - works in Gerrit really well, but the "comments thread" is tied to a particular "file version", so the "thread" does not "flow" to the updated file
• Explicit "approve/block" life cycle. - works in Gerrit perfectly: in Gerrit you "vote" on a change, for example +2 "lets merge it", +1 means "I like it", -1 means "I do not like it", -2 "Do not ever merge"
• Incremental diffs - that is what sold me to Gerrit, you see diffs between old and updated commits! The only issue here is when updated commit is also rebased onto new commit on "master", then you see both changes introduced in this updated commits and changes introduced by the new commits on master.

+1 for resolve comments

+1 for the 1st, 2nd and 4th point, these would all be highly valuable to me as well.

+1 for resolve comments and reply

Any news on this? With automatically folded comments we can't distinguish between those that are resolved and those that are not. This has been a problem for years. Could we override the folded status of a comment please?

Any news on this?

👍

+1 for manually resolving comments

+1

+1

+1 for resolving comments manually; I don't understand why you would add "reactions" to comments before adding a "resolve" feature.

It looks like someone added an issue for "Mark command as resolved" in the "dear-github" project: dear-github/dear-github#154

My assumption is that github people are watching this repo. Hopefully we'll get a few more reactions to help them prioritize it.

+1 for resolving comments manually

+1 for resolving comments manually

+1 for resolving comments manually

👍 for "mark comment as resolved"

+1 for resolving comments manually

+1 for resolving comments manually

+1 for resolving comments manually

+1 for resolving comments manually