GitHub Community
Review comments not shown in "Files changed" if a commit affects the comment's associated line #23138
-
|
Consider the following situation:
Then, going to the “Files changed” tab of the commit, one can see the changes, as well as review comments, but the review comment that was associated with the line that has been modified is not shown. Having the comment thread shown there would enable resolving the conversation straightway, since the commit would typically address the comment. Is this an intended behaviour? |
Beta Was this translation helpful? Give feedback.
Replies: 43 comments 12 replies
-
|
Yes, this is the intended behavior. If the line that the comment was in relation to changed, the automatic tools have no way of knowing if the comment targeted at the old line still makes sense on the new line. You can, however, always see the full conversation on the Conversation tab. Any comments referencing lines that have been changed show with an “Outdated” flag: You can see this example for yourself in my test repository. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
@lee-dohm is there any news on this after 4 years? |
Beta Was this translation helpful? Give feedback.
-
|
I've become absolutely paranoid of missing comments (as a reviewer) over time, and I'm now realizing that this is why. It makes it feel unstable - like conversation threads can seemingly disappear but still keep the PR open. It makes the tool feel flaky and unreliable. I really just want it to show me all unresolved conversations, even potentially outdated ones. Not doing so makes it systematically difficult to determine whether or not a comment was truly addressed by a change intended to do so. Often times it's just a one-line change that makes the conversation vanish from the Files Changed view! It's maddening. I'm hitting my thumb with this hammer so often that for the first time ever, I'm considering finding a different review tool for myself and my team. I honestly wouldn't have considered using something else if it weren't for this one bug / missing feature. Add this, and GH code review will be a pretty decent tool. |
Beta Was this translation helpful? Give feedback.
-
|
I just stumbled upon this after doing a self-review of some of my code and then cleaning up a few lines, then seeing all of my comments that I left for my team were now marked as Outdated and not visible in the review page... It's madness that there is no way to at least manually show Outdated comments or mark them as not Outdated. Seriously, how much effort does it take to make the |
Beta Was this translation helpful? Give feedback.
-
|
Today I found myself advocating to move away from GitHub to something else because of this very issue. I happen to know for a fact that Gerrit handles this well. I find it extremely surprising that anyone would think the way that GitHub handles this is acceptable, let alone preferable. Unfortunately, I suspect that this conversation is being ignored by GitHub staff, because this issue has been marked "Answered." 😢 |
Beta Was this translation helpful? Give feedback.
-
|
Just chiming in to bump the thread (if it does, in fact, get bumped anywhere). This is supremely annoying behavior. The only standalone workaround is to keep two tabs open to bounce back and forth between the Conversation thread and the Files Changed screen, and even then you can't easily see exactly what's going on. I also didn't realize at first that the default behavior is not to "show all changes" in the commit dropdown on the Files Changed screen. I couldn't figure out why I wasn't seeing my coworker's latest commits addressing my comments, which is literally the whole point of reviewing a PR. (Another workaround that at least sometimes works is to leave comments only at the file level with a mention of the line number, rather than inline with the code, but that's annoying for both reviewer and developer, especially on longer files.) And if this was the only issue, maybe I wouldn't be so thoroughly vexed, but there are too many UI/UX issues that add up to a massive pain in my hindquarters every time I need to review a PR, which is nearly daily. It feels like no user testing in a real business environment has been done at all. |
Beta Was this translation helpful? Give feedback.
-
|
This is a stupid and limiting design IMO. If I make a comment on a line, and that line is changed to fix what I commented about, I want to be able to verify that the comment is fixed. I can’t do this in the Conversation tab view, since the fixed code isn’t shown there. I can’t do this in the Files changed tab view (selecting the commit with the change), since the comment isn’t shown there. Basically, this design forces me to open two different browser windows, and cross-comparing the Conversation view with the Files changed view. Sure, the code file that the comment is in might have changed drastically, making the comment obsolete, but I rather think that the risk for that is very low compared to the chance of the file changing due to the actual comment. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly that. If I write a comment in a PR, I want to see how that comment is answered (either by reply, or by code change). If I have to look through all code changes to see what possibly has been done, it takes me ages to see if I can set the comment to resolved. |
Beta Was this translation helpful? Give feedback.
-
|
What's especially frustrating is that even a one-line change causes this problem. For example:
Now, the conversation is completely absent when looking at This get totally ridiculous to deal with in reviews with many trivial change requests. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, whether or not the line changed isn’t as much of a big deal as having to pop open a new tab to review the conversations at the same time as being able to view the updated code. It is actually harder for me to track the conversation to the changed line than it would be if the comment were still attached to an incorrect line. We used to deal with that all the time in Swarm; when it was off by a few lines, it was ok because we knew from the comment what the original code was, and could scroll back to wherever the new relevant line was. But it was much easier to immediately review the new code to the comment than it is to have to pop open two tabs, and then manually try to line up the new code to the comment. Note to others, you can almost kind of sort of simulate this if you expand the commit drop down (upper left of the code panel) to include more than the past one commit. Unfortunately, you may accidentally then display code from other commits that occurred in between. But in this way I was actually able to see the original comment, and see the new code. I did this by resetting the view to split mode. I’m not sure this always works though, or works as intended. |
Beta Was this translation helpful? Give feedback.
-
I understand that the tooling will not know if the comment makes sense at the new line, but it could be attached to the same line in the left pane, and then it can be left up to the user whether to resolve it or not. This would make it *so* much easier to review large pull requests with lots of comments. In the worst case, I would prefer to have the old comment still show up, but attached to the potentially wrong line if things have changed substantially. At least it would be near the correct code, and it wouldn’t require me to flip back and forth between two windows, and manually look up where in the code the comment applies. Can we file a feature request somewhere? :slight_smile: |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree. This makes it way more difficult than necessary to figure out if the comments that were marked “resolved” have in fact been resolved. |
Beta Was this translation helpful? Give feedback.
-
|
I agree! This is the feature I would like to have: if I click the [Outdated] tag, I get a split view where on the left I see the commit I have commented on together with the comment and on the rigth side I see the newest code with all the changes that have happened since. |
Beta Was this translation helpful? Give feedback.
-
|
Bumping this response, four years later... This is exactly what I would want. |
Beta Was this translation helpful? Give feedback.
-
|
of course we need this feature. |
Beta Was this translation helpful? Give feedback.
-
|
Adding my voice to those who argue the current behavior is problematic. It’s entirely confusing that some comments will still show in the “files changed” view while others don’t. For a while, I didn’t even realize this behavior was happening and I’ve been missing a lot of these disappearing comments as a result. As others have said, it’s really not a big deal if a comment doesn’t “make sense” anymore due to a change in the file. I can easily resolve it or create a new comment. It IS a big deal if I lose track of and fail to address important comments in a PR because they are missing. Jumping back and forth between two tabs is not a solution. The files changed tab is the sensible place to do the work of reviewing a PR as that is where the context is. EDIT: Even worse, I’ve just realized that the “outdated” comments that show in the Conversation tab will only show the outdated code. Thus, there’s no easy way for me to verify that the change has addressed the feedback in order to resolve the comment. AFAICT, the only way is to switch to the files changed tab and scroll around looking for the change in question, verify the comment is addressed, then go back to Conversation view and mark as resolved. This is totally impractical. |
Beta Was this translation helpful? Give feedback.
-
|
This is one of the stupidest “intended behaviors” ever. You need to have 2 tabs open to review any change because “Github attaches comments to commit hashes” (probably because that was the easiest way to implement it). I want to see how a comment got fixed. Just look at Bitbucket for example. Even if lines get updates, comments still show up at the correct place. EVEN if you force-push, the comment remains. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any issue related to that topic we can raise ? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this is one of the biggest gripes our users have that prevents us from migrating away from Gerrit. |
Beta Was this translation helpful? Give feedback.
-
|
@lee-dohm I also have similar experience like other. I would like to see on the Conversation tab also changed code, not only “outdated” to be sure it was fixed properly. For larger PR it is problematic not having easy way to resolve issues and be sure they were fixed in proper way. |
Beta Was this translation helpful? Give feedback.
-
|
Another commenter mentioned this, but BitBucket gets it much better than the current GitHub behavior. I’ve never had this level of confusion doing large PRs with BitBucket, switching to GitHub has made it really difficult keeping track of comments across multiple commits in a PR. The current behavior definitely deserves some more finessing, it’s such an important and core capability of GitHub and any git-based tool. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
+1 to all this. I use gerrit now and it does this so it took me a long time of troubleshooting to figure out the issue wasn’t with me, but the feature isn’t present. Please fix! |
Beta Was this translation helpful? Give feedback.
-
|
we've been complaining about this for years. there are even SASS companies profiting off this exact problem with the github UI. FIX IT ALREADY |
Beta Was this translation helpful? Give feedback.
-
|
I'm somewhat flabbergasted at this. As the lead of a team where we try to make reviewing code as efficient as possible, knowing that a comment has been addressed is of paramount importance. Further, in the name of code review speed, knowing that the ONLY change between one review and the next is code that addresses a comment is EXTREMELY valuable as the reviewer can just do a simple diff. But not in github... |
Beta Was this translation helpful? Give feedback.
-
|
In user story format: As a code reviewer, I want to see in a PR what the new code is where my newly resolved comment on old code was, so that I can ensure my concerns were addressed. (Currently the comment is shown with the old commit but not with the new commit and it is a hassle to figure out what the new code is for a resolved comment.)
No other code review tool gives up when it can't know exactly if the comment is still relevant. The reviewers have the context of earlier reviews in mind and can work it out, but not if they don't see the comment. |
Beta Was this translation helpful? Give feedback.
-
|
Adding my voice to this. When reviewing a new or junior developer's code I can't just assume that they properly addressed each specific comment, I need to be able to easily see what code changes they made. Even if the review comments were simply linked to specific lines in the file (instead of commit hashes) that would be useful. |
Beta Was this translation helpful? Give feedback.
-
|
Having enjoyed the Azure DevOps and Bitbucket commenting systems for years, I always thought I was doing GitHub PR commenting incorrectly because they wouldnt track when code was updated. Finding this discussion is both baffling and reassuring. I'm confused why such a strange UX decision would be considered "correct" and happy to find out that it's not me, it's GitHub. 🤦♂️ I would love for this "feature" to finally be considered a bug and corrected. |
Beta Was this translation helpful? Give feedback.
-
|
A few months suffering with this I finally took the time to research about it and I find this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
I review a lot of private code and sometimes I can't remember what I have said earlier. Making it very hard to verify if the made change is the requested change. Especially with 50+ comments for each review. I do not want to see the old code, I just want to see what my comment was or the comment of my colleague. |
Beta Was this translation helpful? Give feedback.
-
|
100% agree, please let us see outdated comments in the "files changed" view or make it an opt-in 🙏 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Adding my vote for this as well. And even if it's intended behaviour, it's not even consistent. One comment will have "outdated" on the Conversation tab when the code is removed. But if the code has changed, you don't see a single thing. Horrible UX... ETA: the more I look at it, the more I'm convinced this is absolutely a bug. It just doesn't add up. Look at this situation: 
It says (6) in the top left Conversation tab. So 6 conversations total. Then on the dropdown (and it doesn't change if I change it to "Changes from all commits") it says (4) unresolved conversations and (0) unresolved conversations. That's just wrong - where did the 2 others go? We definitely need at the very least a way to look at the old comments here. This was the code change that wasn't even flagged as "outdated" - but it did hide the comment that was attached to the line: Auto-resolving it? Then why isn't it shown as "resolved"? Whichever way you look at it, it's implemented inconsistently at very best. And if I switch to watching the files of the commit that the first review was done for, the comment doesn't show up either. This is just a bug. |
Beta Was this translation helpful? Give feedback.
-
|
There is a solution on Azure DevOps and it's perfect, Github should implement the exact same mechanism. We wouldn't imagine that moving some projet from Azure DevOps to Github would cause us to lose features. Microsoft product owners should discuss together 😄. |
Beta Was this translation helpful? Give feedback.
-
|
GitHub and MIcrosoft are one now right? Just do what Azure DevOps does. I can't believe it's going on 4 years since this was reported and it's still not addressed. |
Beta Was this translation helpful? Give feedback.
-
|
This issue is crazy, but what's worse is GitHub's silence about it. This post was created in 2019, and here we are in 2024, still waiting for an answer... Can you stop mocking your users so openly, GitHub? |
Beta Was this translation helpful? Give feedback.
-
|
This is one of the most maddening lack-of-feature I found after switching to GitHub. This makes code reviewing so much more painful compared with Phabricator or gerrit. Come on github devleopers! If Phabricator can implement it with its small team, surely you folks can do it as well. I made a new feature requests in the Pull Request section of the board so that hopefully some PM will read it. Please vote there as well if you want to see it implemented (https://github.com/orgs/community/discussions/110796) |
Beta Was this translation helpful? Give feedback.
-
|
this is ridiculous |
Beta Was this translation helpful? Give feedback.
and others
Yes, this is the intended behavior. If the line that the comment was in relation to changed, the automatic tools have no way of knowing if the comment targeted at the old line still makes sense on the new line. You can, however, always see the full conversation on the Conversation tab. Any comments referencing lines that have been changed show with an “Outdated” flag:
You can see this example for yourself in my test repository.
I hope that helps!