GitHub Community
Cant easily see changes to a file in a conversation in subsequent commits #9956
Replies: 37 comments 38 replies
💯 This topic has been a significant source of frustration for me since my team switched to GitHub. When I take the time to comb through someone else's code and request changes, I need to be able to reference those requests while reviewing their new commits. One possible solution that GitHub could implement: Next to the |
|
My company has just recently switched from Azure DevOps Git Repos to GitHub. I have to reluctantly acknowledge that the Microsoft Azure offering has a significantly better experience here. They do this.. and do it fairly pretty well - it updates nearly live as new comments and pushes to the PR branch come in. |
|
We switched from bitbucket. They had 4 ways of helping solve this
There where a few other enhancements made that made Bitbucket PR a better experience overall but they are not related to this topic.
|
|
My current workaround solution is to just have the conversation open in a separate window and manually search for the file. The problem is not as bad on small PR's but managing this on large PR's is a nightmare |
|
This is what I have been doing as well, and I miss ADO so bad already because of this.. |
|
same here.. I thought ADO is the legacy product and github sets the gold-standard here, but in a big PR its really hard to keep an overview, if the reviewrequester really implemented suggestions or not. |
It's not, but FWIW in the regular timeline when the developer force-pushes (replaces) the commits of the PR there's a note saying:
Well it's completely invisible because it was specifically styled like regular text but the words "force-pushed" are actually hyperlinked to the textual diff between commit1 and commit2 (unlike the link from the notifications which links to nothing). That aside, if you have the possibility you may want to take a gander at reviewable.io which has a much more complete and flexible flow especially for reviews which are not trivial. Amonst other things they have what are essentially "review points" orthogonal from the commits and PR updates. It's a layer on top of github (and in fact works only with github) so it's not something you have to change everything over. |
|
Looks nice, except the UI was drawn by a 4th grader with a crayon. But the real deal-breaker is that for public repos, the whole PR flow is hidden away on an external service. It would only be usable if the comments created there could be viewed and replied to natively on Github too, and vice versa. That way anyone browsing Github would be able to view and participate in the discussion related to every PR without having to sign up for an external service. |
|
I wonder if it would be possible to write a GitHub Action that automatically links to the correct external review from GitHub. |
|
@Kurt-von-Laven Reviewable adds a big button to the PRs it starts handling. That's actually why I couldn't use it myself: I just wanted to use it under the covers to make reviews easier on large PRs where github is really bad, but the big button was a bit too visible. |
|
Does anyone know if there's any planned work at github for this? This seems like a pretty core feature that is frankly a huge step down from bitbucket's or Azure devop's PR experience. |
|
It is possible to jump through the conversations and comments within the Go to: Find there the submenu: |
|
that doesn't show the conversations whose context lines have been changed, does it? |
|
Nope; if you jump to a resolved conversation, it only shows the commit where the conversation was made, not any of the changes made afterward. So you can't verify the changes against the suggestion without going back and forth or opening multiple windows. |
|
This is frustrating coming from GitLab and so weird that this doesn't work well. Hopefully there will be an improvement coming soon |
|
Maybe a couple of upvotes make them work on this... |
|
This is a source of significant frustration. Any feedback from GH would be massively appreciated. |
|
Coming from Gitlab, I thought it was me who could not understand how to do such a basic thing while reviewing. Then I bumped into this discussion. IMHO current behavior makes the whole review process an unmotivated pain, and it is a valid reason to hop to another tool. |
|
Same here! "Coming from Gitlab" |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Thank you ChatGPT for your invaluable wisdom! |
|
-- brought to you by Open AI |
|
I came here looking for a solution to exactly this problem since my company migrated from BitBucket to Github. This is quite frustrating. How is it possible that nobody has deemed this issue to be top priority? We must be missing something, this is such a basic process of reviewing PRs. Either that or we're using a whole different review paradigm than the folks at github are when they're going over their own changes. |
|
if github won't support this. I hope refined github will. |
|
Refined only does UI tweaks, this is way too involved for that. You need a complete layer of additional metadata over github to fix it, as in Reviewable (which does in fact fix this, amongst others). |
|
I don't think extra metadata is necessary. Just display all existing comments, regardless of their commit checksum, when showing the latest version of a file. All you need is the file name and line number attached to each comment. |
|
Anybody have an idea how to download the conversation changes to my own computer for testing? This isn't documented anywhere. |
|
That is what is on the head branch like @paulius-valiunas said. |
|
If a PR would be in HEAD already, why bother accepting the request? |
|
The head of the PR, not the head of the target repository. You can clone the repository the pull request comes from to check out the branch, or you can use github's magic pull refs to just check them out. Now please move this subthread somewhere else, it has nothing to do with the subject. |
|
Well, maybe this should be documented somewere? |
|
no need to document this, it's not specific to github, it's just git 101. A "pull request" is a request to merge one branch into the other. If you want to see what is on the branch, just checkout the branch. There is no such thing as "contents of a PR" - there are only contents of a branch that someone wants to merge into another branch (the "other branch" is usually master or main). |
|
Actually, it's not 101. If I have to ask, I don't know this. Having a few words in any documentation wouldn't hurt. |
I think this makes it perfectly clear that the changes discussed in a PR reside on a branch. If you still need additional clarification after reading that paragraph (which is literally the first paragraph on the page about PRs), you can continue reading here: I think the documentation is more than sufficient. |
|
Thank you for the completely useless links. I'm concluding this fruitless ping-pong and moving forward to find actually usable documentation on how to work with evaluating pull requests. Theory on PRs and documentation on branches don't do the trick here. |
|
🤦♂️ |
|
@paulius-valiunas I guess that @Cap-JaTu want to know if is it possible to review changes on a branch before GitHub auto-closes conversations. When you leave a comment on someone pr's in GitHub, if he push some code that overwrites the lines of the commented part, GitHub sometimes auto-closes conversations and you lose the content of that messages (actually you can go back commit by commit and view the changes, but in my opinion this option isn't fast and stress-less enough). Maybe I didnt understand a thing about your convo |
That's an entirely different interpretation I haven't considered. @Cap-JaTu, did you want to download the comments instead of source code? In that case I can't really imagine in what format they would be stored for download, and I don't see the point either because comments are never deleted (unless you delete them explicitly). @robertodraGit Github doesn't auto-close conversations, it just stops displaying them in the files tab. You can still see them in the conversation tab. |
|
Bump, this is a really big UX issue, enough to consider moving to Gitlab or Bitbucket which do manage this |
|
Coming from Azure DevOps and really frustrated with this behavior. Even more frustrated now knowing every other version management platform works correctly except for GitHub. |
|
I second that. |
|
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! |
|
Glad to know I'm not crazy for thinking this should be a feature. Juggling multiple reviews in parallel is made really difficult by this! |
|
Another six months, another new bump. Still awaiting any functional response to any of the (at least) four discussions about this issue over six years. This is still making my PR review process profoundly annoying. |
|
Maybe we can rephrase the issue to use copilot, then they'll get on it :) |
|
This is absolutely terrible. |
|
Are there any plans for fixing this? |
|
On VS Code, after you signed in GitHub, there should be a "Comments" view, and we will see all comments there (marked as outdated) |
|
Just switched from Azure Dev Ops to GitHub. This thread is so accurate. Are there any plans for fixing this? |
Same here ... |
|
We've just moved from DevOps and also struggling with this! |
|
+1 to the issue, I thought it was just me not understanding the interface (after coming from Gitlab), but now I realised that this very basic feature is missing? :( |
|
This is a huge pain point for us as well. |
|
+1 in 2026. Coming from DevOps, where this is handled well, it’s surprising to see such a limiting design choice. |
|
Could this finally be fixed? |
|
I'd recommend we all go boost the open feature request listed below. This issue has been documented in (at least) the four threads below since 2019. I wonder if we're going to make it to a decade with no fix... |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm finding this quite an infuriating part of the "conversation" in reviews. This is what Im finding:
If I click "view changes" it just displays all the files in the PR not the one with the comment. For large PRs this is a pain as I have to find the file, and then go to the latest commit. But when viewing that file, there is no trace of my original comment / conversation so I cant easily recall where the comment was or what it was about so I have to click back to the conversations list to find it again.
On top of this, when seeing the list of "viewed" files in a PR (i.e. theyre collapsed), there's no indication as to which ones have comments in them. So I have to unclick "viewed" on each of them to see if there was a comment in there that need to be re-reviewed.
Either I'm missing something or this isn't very well thought out?
All I want is for the conversation history to persist in the file across all commits so I can ascertain that the author has indeed made the fix they claim to have
All reactions