Cant easily see changes to a file in a conversation in subsequent commits

[sparmboy]

I'm finding this quite an infuriating part of the "conversation" in reviews. This is what Im finding:

• Add conversation to a file in a PR
• Author adds comment of something like "done" and pushes new commit to address the change.
• As reviewer, when reviewing this change, I can see the comment that author has fixed but no way of seeing what the change is.

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

[Acorath]

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

💯

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 View changes button for a comment in the discussions view, add another button along the lines of Compare to latest changes, which would select every commit added to the pull request since the comment was made. If the commented code was altered in any way, then the comments should be displayed on the left pane along with the original changes that were commented on.

[hazz0003]

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.

[dcumings]

We switched from bitbucket. They had 4 ways of helping solve this

1. Conversations show in side tab and take you to the current version of the file and directly to the comment in the current context if possible.
2. When possible the comment would still remain exactly where it was left even if the file changed around it.
3. If the file changed to much the comment would be listed at the top of the file with the ability to pop up the comment and the context of where the comment was at the time the comment was made.
4. If the file was gone you could always pull up the comment and context as a pop up from the side menu.

There where a few other enhancements made that made Bitbucket PR a better experience overall but they are not related to this topic.

[dcumings]

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

[saleazer]

This is what I have been doing as well, and I miss ADO so bad already because of this..

[flobacher]

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.
please fix this 🙏

[xmo-odoo]

Either I'm missing something or this isn't very well thought out?

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:

@user force-pushed the branch from to

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.

[paulius-valiunas]

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.

[Kurt-von-Laven]

I wonder if it would be possible to write a GitHub Action that automatically links to the correct external review from GitHub.

[xmo-odoo]

@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.

[jababda]

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.

[aramyesildeniz]

It is possible to jump through the conversations and comments within the Files changed tab, which allows you to quickly see which file and line is affected and eventually got changed.

Go to: Pull requests -> Files changed

Find there the submenu: Conversations -> Jump to conversation

[paulius-valiunas]

that doesn't show the conversations whose context lines have been changed, does it?

[asilverman-stripe]

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.

[clemwo]

This is frustrating coming from GitLab and so weird that this doesn't work well. Hopefully there will be an improvement coming soon

[robertodraGit]

Maybe a couple of upvotes make them work on this...

[ben-polinsky]

This is a source of significant frustration. Any feedback from GH would be massively appreciated.

[klinamen]

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.

[klinamen]

Thank you ChatGPT for your invaluable wisdom!

[myedibleenso]

-- brought to you by Open AI

[carlospnav]

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.

[stephenjason89]

if github won't support this. I hope refined github will.
Please upvote this
refined-github/refined-github#7048

[xmo-odoo]

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).

[paulius-valiunas]

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.

[Cap-JaTu]

Anybody have an idea how to download the conversation changes to my own computer for testing? This isn't documented anywhere.

[Kurt-von-Laven]

That is what is on the head branch like @paulius-valiunas said.

[Cap-JaTu]

If a PR would be in HEAD already, why bother accepting the request?
There has to be a flaw in logic where all the changes in a non-approved pull request will appear in HEAD.

[xmo-odoo]

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.

[Cap-JaTu]

Well, maybe this should be documented somewere?

[paulius-valiunas]

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).

[Cap-JaTu]

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.

[paulius-valiunas]

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

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:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
... which in turn has a link to this:
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

I think the documentation is more than sufficient.

[Cap-JaTu]

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]

🤦‍♂️

[robertodraGit]

@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

[paulius-valiunas]

@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.

[didmar]

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

[Caitlin-Syntax]

Adding my bump here in addition to discussions 17481 and 23138. This issue continues to frustrate me regularly.

[Tommuh]

Doing daily 10+ reviews. I cannot remember what I have said, it is difficult to verify if the asked changes are actually applied.

[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 (this thread)
• https://github.com/orgs/community/discussions/17481
• https://github.com/orgs/community/discussions/23138
• https://github.com/orgs/community/discussions/110796 (feature request)

[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.

[tabiStein]

Chiming in to add to the numbers. This is horrible. Makes me really miss SmartBear's Collaborator tool, the gold-standard "ideal" code reviewing experience (I think) -- except that it's a separate tool on top of version control. Would be nice to have such a great experience integrated into Github PRs.