"File" comments all get outdated when you push anything, even if that file isn't touched

[hepcat72]

Select Topic Area

Question

Body

This may make some technical sense for some reason unknown to me, but I think the retention of comments should at least be attempted if a push doesn't touch that file.

[nickkipshidze]

GitHub comments on specific lines or sections of a file are associated with a specific commit. When you push changes to a repository, GitHub creates a new commit for those changes. Even if the changes are made in a different file, the commit hash is different. If you push changes to the repository, GitHub considers the comments as associated with a previous commit, and it marks them as outdated.

I hope that helps.

[nickkipshidze]

Also, instead of commenting on specific files you can comment on whole pull request. That way it wont get marked as outdated. Using pull requests for discussions is a good practice.

[hepcat72]

Speaking to empirical observations (not to how it works), this isn't entirely true. Comments on specific lines are not outdated when those lines aren't changed. I literally just went through all the comments in a PR after a push and all the comments on specific lines were retained (not outdated), but every file comment was marked as outdated.

In our code reviews, we create issue comments on lines. Those issues are addressed and changes pushed. Comments attached to changed lines get outdated, but those not on changed lines remain.

I don't claim to know the inner workings. I'm just speaking from lots of experience using PRs for code reviews.

And when comments pertain to a file but do not have relevance to a specific line, like a discussion about why the file was added or removed, then attaching that comment to the file and not a particular line makes a lot of sense and I would argue is good practice - better than what we used to do before the ability to comment on files was introduced.

Lastly, commenting on the PR is inadequate because issues brought up there do not get a "resolve" button.

[chinanderm]

This behavior is incredible frustrating.

[hepcat72]

It's inane. I've gotten into the habit of commenting on the top line instead of using the file comment feature, since doing so almost always creates a lot of repeated work transferring comments to retain them. It's less than useless the way it is now. It actually creates braindead work.

[GarethChetwood]

That's the exact problem I'm experiencing; having to recreate comments on files after a push! It incentivises just using top-line comments (which is exactly what we were doing before this feature was added).

I appreciate why it works the way it does, based on @nickkipshidze's comment, however there must be a workaround, in its current implementation the feature is useless-adjacent.

[hepcat72]

But if that's how it works, then why are comments on lines of a file retained when that file is changed in a push to the PR (unless the comment is on changed lines)? Based on @nickkipshidze's logic, it seems like all comments on a file changed in a push should be outdated, but that's clearly not the case. Why don't the file comments work the same way we observe with comments inside the file?: retained unless the name of the file or its location changes?

[hepcat72]

I mean, why would commenting on the top line of a file produce a durable comment that persists between pushes if comments are attached to commits and I pushed a new commit?

I'm sure there's probably a technical explanation about the difference between a comment on a "line of an unchanged file" and a comment on an "unchanged file" that explains the behavior difference, but if there is, it doesn't change the fact that it makes comments "on files" more difficult to follow up on compared to comments on the top line of a file.

[tbottomparallel]

Top line commenting is not possible for submodule changes & diffs large enough that github refuses to render them. To comment on such changes in a PR you need to use the "file" comment, and it is so very incredibly annoying.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[CollinDietz]

Commenting to say that I also want this fixed/changed

makes the on file comment feature basically useless and I default to comments on the top of files like others here

[cbeck-wandrian]

Working as intended and then silence is possibly a worse response than silence alone.

[jazithedev]

I'd like to get it fixed as well ☹️.

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

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[cbeck-wandrian]

+1 to stop the auto-close

[hepcat72]

Meh. This isn't an issue. It's a "discussion". The "answer" is to change the feature so that comments attached to files persist through pushes the same way that in-file comments (that aren't inside changed code) do. And to be precise, the only things that should make a file-attached comment stale should be thing like:

• file name changed
• That's pretty much it

The Things that shouldn't make a comment stale are:

• changes inside the file
• Permissions change
• Deletion of the file
• moving the file

I mean, just think about it. Comments on lines of a file persist even when the line above and the line below change. You could even make a case that if the file name changes, you could keep the comment.

But the minimum bar should be: if nothing about the file changes: make the comment persist through a push.

So the result of this discussion should be the creation of an issue that establishes these new feature requirements. Then this discussion can be closed as answered.

[hepcat72]

...if an issue doesn't already exist