GitHub Community
Dear GitHub, you are missing such a basic concept in ways that are incredibly frustrating #17481
Replies: 3 comments 2 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @didmar for pointing out another unanswered post on the one I referenced above. |
Beta Was this translation helpful? Give feedback.
-
|
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( This is all to say that the requested behavior is entirely possible, and I too am missing it greatly in Github. |
Beta Was this translation helpful? Give feedback.
-
|
Bump, this is a really big UX issue, enough to consider moving to Gitlab or Bitbucket which do manage this |
Beta Was this translation helpful? Give feedback.
-
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
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.
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions