Is your feature request related to a problem? Please describe.
I do most of my PR reviewing from gh-dash and the activity panel keeps tripping me up on anything bigger than a tiny PR. Two things in particular:
When a reviewer leaves a comment on a line and someone replies, the reply doesn't show up under the original — everything in the activity list is sorted by timestamp, so a reply can land next to an unrelated approval or general comment that happened to be posted around the same time. By the time a thread has 3-4 replies it's basically a guessing game which message is replying to which.
The other half of the problem is that review comments are headed with just path/to/file.go#l42 and nothing else. On github.com the snippet of code the comment is anchored to is always shown above it, and that's what makes the comment make any sense. Without it I'm constantly tabbing out to the browser to figure out what line someone is even talking about, which kind of defeats the point of reviewing from the terminal.
Describe the solution you'd like
Group comments by their review thread instead of flattening them. Order threads by when the first comment was posted, and render the replies indented under the parent (or with a faint left border, whatever fits the existing style). General PR comments and reviews can keep interleaving as top-level entries.
Above each thread, show the diff hunk it's attached to — same idea as github.com. From a quick poke at internal/data/prapi.go the ReviewComment fragment doesn't fetch diffHunk today, but adding it looks like a one-field change, and the existing markdown renderer would handle the syntax highlighting.
While you're in there, the IsOutdated flag on review threads is already being fetched and then thrown away — would be nice to surface that visually too (struck through, dimmed, whatever).
Describe alternatives you've considered
Discussion #371 suggests color-coding authors to make threads easier to follow. That helps a bit but it's a different problem — it makes people distinguishable, not threads.
I also looked at the pr-view branch from #381. It looks great but it's a much bigger redesign and seems to have been on hold for a while; threading + snippets feels like something that could land in the existing preview without waiting on that.
The fallback is just hitting o to open the PR in the browser, which works, but at that point I'm not really using gh-dash to review anymore.
Additional context
Related: #381, #371, #490.
The reviewThreads query is already capped at 50 threads × 20 comments, so adding diffHunk shouldn't blow up the node count.
Happy to split this into two issues (threading vs. diff hunks) if that's easier to triage — they're related but they're independent enough that one could ship without the other.
Is your feature request related to a problem? Please describe.
I do most of my PR reviewing from
gh-dashand the activity panel keeps tripping me up on anything bigger than a tiny PR. Two things in particular:When a reviewer leaves a comment on a line and someone replies, the reply doesn't show up under the original — everything in the activity list is sorted by timestamp, so a reply can land next to an unrelated approval or general comment that happened to be posted around the same time. By the time a thread has 3-4 replies it's basically a guessing game which message is replying to which.
The other half of the problem is that review comments are headed with just
path/to/file.go#l42and nothing else. On github.com the snippet of code the comment is anchored to is always shown above it, and that's what makes the comment make any sense. Without it I'm constantly tabbing out to the browser to figure out what line someone is even talking about, which kind of defeats the point of reviewing from the terminal.Describe the solution you'd like
Group comments by their review thread instead of flattening them. Order threads by when the first comment was posted, and render the replies indented under the parent (or with a faint left border, whatever fits the existing style). General PR comments and reviews can keep interleaving as top-level entries.
Above each thread, show the diff hunk it's attached to — same idea as github.com. From a quick poke at
internal/data/prapi.gotheReviewCommentfragment doesn't fetchdiffHunktoday, but adding it looks like a one-field change, and the existing markdown renderer would handle the syntax highlighting.While you're in there, the
IsOutdatedflag on review threads is already being fetched and then thrown away — would be nice to surface that visually too (struck through, dimmed, whatever).Describe alternatives you've considered
Discussion #371 suggests color-coding authors to make threads easier to follow. That helps a bit but it's a different problem — it makes people distinguishable, not threads.
I also looked at the
pr-viewbranch from #381. It looks great but it's a much bigger redesign and seems to have been on hold for a while; threading + snippets feels like something that could land in the existing preview without waiting on that.The fallback is just hitting
oto open the PR in the browser, which works, but at that point I'm not really usinggh-dashto review anymore.Additional context
Related: #381, #371, #490.
The reviewThreads query is already capped at 50 threads × 20 comments, so adding
diffHunkshouldn't blow up the node count.Happy to split this into two issues (threading vs. diff hunks) if that's easier to triage — they're related but they're independent enough that one could ship without the other.