Feature Request: make inline comment "sticky" across changed lines

[yuanchen-zhu]

Select Topic Area

General

Body

During code review, a fundamental workflow involves the following:

• The reviewer makes an inline comments suggesting some changes
• The author modifies the relevant lines per the suggestions
• During the next round of review, the reviewer checks that the suggestions have been addressed. For the majority of small suggestions, that involves looking at roughly the same region of code around the lines where the original inline comments have been made.

Right now, Github UI has the following 2 issues.

• If a line is changed, then the original inline comment will no longer show up in the "Files changed" tab. It would help developer efficiency greatly if Github makes a best-of-effort attempt to locate the lines in the newer files where the original inline comments should stick to. (Phabricator does a great job doing this. Github should just copy it)
• In the conversation view, where the inline comments made during a code review are collected, it would greatly help developer efficiency if the latest version of the code around the original inline comments are shown, alongside the original code.

Because of the lack of these two features, right now when I want to check that an inline comment has been addressed, I need to manually navigate to the corresponding file and the approximate line number, and read the block of code in the latest checked out PR.

This feature request is basically the same request implied here (https://github.com/orgs/community/discussions/23138), but since that post was in the "New to GitHub" category, GitHub employees no longer seem to look at it. Hence I'm posting a new feature request here.

[gabmis]

100% Agree, I am currently forced to open two windows side-by-side, one on the conversation tab and the other on the files changed tab. Only then, am I able to somewhat efficiently check that my comments have been addressed correctly. Please implement this. There were hundreds of upvotes in the thread from 2019. 🙏 ❤️

[serhii-surazhskyi-gl]

We were forced to switch to Github (from Gerrit) and it is a nightmare comparison to previous review tool/process. Just spending 2-3 times more on review, that at the end of the day is also of less quality, because of possible missing comments (as the tab with comments is also flooded with all the non-related nonsense). Still I'm writing it here just to 'up' the topic without any belief it will be fixed...

Maybe someone will consider this comment useful and will NOT switch to github with such an "amazing" review functionality.

[TharunMJ]

What challenges do you face when switching between the conversation tab and the files changed tab?

[serhii-surazhskyi-gl]

What challenges do you face when switching between the conversation tab and the files changed tab?
As you know some comments are not shown (became outdated) in Files changed tab (also in Commits).
I prefer review each commit separately as it is easier to get intention of the change. But in the Commits tab comments are also lost. They (comments) also messed up there, as review is intended to be only in files changed tab (probably?), so you can see (if it is NOT outdated) a comment for another commit...

To perform a review I need to keep several tabs open: one for Conversation and one for Files changed or Commits (or even for both).
If I don't use 2+ tabs, then clicking on View reviewed changes in Conversation tab does not redirect to the right place in diff - it just points to the begging of Files changed tab, and then "where am I?! Why am I here!?" - probably, very useful feature, but not for me as it does not work. You may also assume redirect from one tab to the other is fast, as they are loaded? Ha-ha, not on github - that takes seconds (or at least not with my environment, however this is out of feature request), so - 2+ tabs are opened.

With 2+ tabs I need to properly "trace" the comment I'm looking at in one tab and the position of it in another tab with the actual diff. This is fine, if I'm already looking at the right commit, otherwise I have to find the right one. Of course, I can check it on Files changed, so no commit search, but why would I, if commits are well-structured?

In between comments in Conversation there can be different other messages: someone added new commits, commented something overall or asked a question, maybe someone even 'resolved' comment by accident, and now it is hidden, or some checker reported something), but I just want to check my comments (or only review related!) are addressed. And those non-related messages have to be read, even they have nothing to do with the actual review comment - that all is time consuming. Seems no filter is available. The whole Conversation looks like a trash can at the end of PR.

It becomes messier and messier the more review iterations are done. Imagine someone new joined the project and you have some 100+ comments? And a reviewer has to track all of those comments the way I described. Not saying that commit messages can NOT be commented, and comments to them in the code (not in the right place as a result!) got outdated really fast!

Of course it is not a problem if PR is 1 commit with 2-3 lines of change and 1-2 comments. But creating a lot of PR's (instead of small commits) is also time consuming.

I hope I was able to explain challenges I face.

[elseifthen]

Spot on. It is a pain to the point becoming unusable in practical situations when you have a non-trivial review at hand.

[simon-knu]

It's the main reason of why I don't want to switch from Azure DevOps to GitHub

The review of PR, especially from new or junior devs, is a nightmare

I think the DevOps system is prefect, it's a pity that we don't have this very basic feature

[Caitlin-Syntax]

This issue is now documented in at least four places with no real official response. GitHub, please, we're begging you. Fix this!

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

[skillmaker-dev]

It's unprofessional seeing GitHub hasn't made any interaction with all the 4 discussions that have been requesting this feature for at least 5 years, it makes the review annoying and makes you think of going back to Azure DevOps, Gitlab, or Bitbucket.
Come on Github team do something about it!

[Tommuh]

Yes - especially for the users who pay a lot of money to use Github. Silence is a killer.

[Caitlin-Syntax]

@detty-down I suggest reading through the feature request and the other threads I linked because our expectations are very clear - we expect to be able to review a typical PR without having to use workarounds. All the other listed tools have that capability. PR review is one of the primary functions of this type of code management tool, and this dysfunctional workflow is adding substantially to the risk that teams lose track of review content and therefore release buggy code, and it also wastes time.

[Caitlin-Syntax]

New year, new bump. This issue, which has been getting upvotes and comments across at least 4 threads since March 2019, still has no official response. My previous comment links to the threads documenting this issue and requesting UX changes. Please, please fix this, GitHub!

[Tommuh]

BUMP !!

[elseifthen]

As far as I understand, gerrit is open source so GitHub devs could have a look at how gerrit does comment tracking across what is called "revisions".

In gerrit, each commit is identified by a unique tracking id (which is added to every commit using a git hook) and you initiate a review by pushing to something like a "review branch" (that automatically has all your local commits, so no squashing of these after a review; you'd have to do that beforehand, which IMO makes sense anyway). Pushing to that branch creates new revisions that are automatically squashed upon merging. If I'm not completely misinterpreting it, that revision-based workflow is fundamentally different from how it is done in GitHub. That said, it is not obvious to me why the comment tracking does not work with GitHub's current approach.