Dear GitHub, you are missing such a basic concept in ways that are incredibly frustrating

[StingyJack]

Its a simple concept, and it shouldn't matter if the PR is large or small, but it does get exponentially worse with larger PR's

• Joe submits a PR
• Bob requests 3 changes
• Joe pushes 3 commits one to address each requested change
• Bob wants to see if Joe has made the requested changes.

As of the time of this post, Bob cannot make this determination easily.

• The conversations tab where the comments all appear just shows "Outdated" and the commit that he added that comment. It does not show the updates that Joe did that made the comments outdated.. It looks like GH expects Bob to click the Resolve Conversation button on this conversation without seeing the code that supposedly resolved it.

  • Why would anyone doing a proper review ever click that button?
  • What is the value in showing the outdated code?

• The files changed tab is equally vexing. Bob can select the latest commit, but that does not show any of the three conversations on it. If he selects a conversation, the commit he selected is automatically changed to the one that originated the comment and he no longer sees the updates that Joe made. There is no way to see the comment and the updated code together unless Bob opens two browser windows to view the PR; one for the comment, and one to see the changes.

  • Why does the commit selection change when the conversation is changed?
  • How do you expect this to be used?

The only thing I can rationalize is that you expect us to treat prior conversations as if they do not exist and treat each review as if it were brand new like a TFVC code review, except that the tools here dont give that impression.

[jchesshirAspire]

I'm glad to see that there is an unclosed version of this closed community discussion from 2019 out here. Linking this conversation to that one will hopefully give GitHub a better feel for just how long and badly this "Intended Functionality" has been annoying their actual users.

[Caitlin-Syntax]

Thank you for calling this out! The "answer" of "yes, we intended this practically unusable behavior" is not a good one - or frankly even acceptable - and there are several recommendations for better UX options in that thread. It's absolutely incomprehensible that this hasn't been addressed when other code management tools handle it just fine. Please, please, GitHub, fix this!!!

As of this point, next time I pick a code management tool for my team, it won't be this one.

[jchesshirAspire]

Thank you @didmar for pointing out another unanswered post on the one I referenced above.

[dsagal]

The "differential" tool in Phabricator (and its successor Phorge, I assume) has great support for this. An "outdated" comment thread generally stays with the line of the file it was associated with across edits and file renames, on a best-effort basis. Sometimes the line is no longer there, and the comment will show up near where it was made, but confusing without the right context. Still, it's useful that it is easy to find, and it is easy to collapse if no longer helpful. In every case, an "outdated" comment is shown in a grey color, so you know it's outdated (applies to a different version of this code). And in every case, it includes a ⏪ icon to open the diff to the commit that the comment was made on, in which case you'd see it in its original non-outdated context.

It also has useful logic for which side of the side-by-side diff to show the comment on, basically choosing the closer commit to the one that the comment was made on. This means in particular that non-outdated comments are always shown on the expected side in the correct context.

A related super-useful feature is keyboard shortcuts to go to next(n)/previous(p) comment. Since all comments, including outdated ones, are visible in the diff, it means that you can scan through all comments easily and know that you didn't miss anything.

This is all to say that the requested behavior is entirely possible, and I too am missing it greatly in Github.

[didmar]

Bump, this is a really big UX issue, enough to consider moving to Gitlab or Bitbucket which do manage this

[IRHayfield]

I agree that GitHub should change this and make outdated comments an optional feature.
As a workaround I created outdated-parrot an action which adds all open outdated comment threads as annotations so they are displayed in the files changed view.
This is not an perfect solution, but does allow users to review comments against the correct line with the addition of some links that users may find useful.

[Caitlin-Syntax]

This issue is now documented in at least four places with no real official response.

• https://github.com/orgs/community/discussions/9956
• https://github.com/orgs/community/discussions/17481 (this thread)
• https://github.com/orgs/community/discussions/23138
• https://github.com/orgs/community/discussions/110796 (feature request)

[bdaz]

As a longtime user of Phabricator (Differential) internally at FB, I desperately miss this UX. The flow described in the original post on this issue is both basic and crucial, and without proper support for it, it takes two windows to review requested changes on GitHub (and even then, it's a lot more work).

Please fix this GitHub! Without it, I'm likely to end up switching back to Phabricator (now Phorge).

[CoolGoose]

I guess we need to bump all a bit more, it's the most annoying thing coming over gitlab, initial context of seeing how the new change 'fixes it' it's important.