Skip to content
This repository has been archived by the owner. It is now read-only.

Allow commenting on non-pull-request code #284

Open
dmugtasimov opened this issue Oct 31, 2014 · 88 comments
Open

Allow commenting on non-pull-request code #284

dmugtasimov opened this issue Oct 31, 2014 · 88 comments

Comments

@dmugtasimov
Copy link

@dmugtasimov dmugtasimov commented Oct 31, 2014

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
Copy link

@RSully RSully commented Oct 31, 2014

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

@Mithgol
Copy link

@Mithgol Mithgol commented Nov 1, 2014

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
Copy link
Collaborator

@cirosantilli cirosantilli commented Nov 4, 2014

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

@pb-cdunn
Copy link

@pb-cdunn pb-cdunn commented Jan 21, 2016

+1

nealmcb referenced this issue in nealmcb/github-workflow-testing-sandbox Jul 17, 2017
To be used for testing github ux etc
@maiamcc
Copy link

@maiamcc maiamcc commented Jun 11, 2018

+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
Copy link

@holtzermann17 holtzermann17 commented Aug 8, 2018

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

@aubergine10
Copy link

@aubergine10 aubergine10 commented Aug 10, 2018

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
Copy link

@alranel alranel commented Aug 17, 2018

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
Copy link

@davidt-secondmind davidt-secondmind commented Nov 2, 2018

+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
Copy link

@DevinBirtciel DevinBirtciel commented Dec 3, 2018

Is anything happening with this?

@bordumb
Copy link

@bordumb bordumb commented Dec 5, 2018

+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
Copy link

@davidstanke davidstanke commented Dec 12, 2018

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
Copy link

@farrukhnajmi farrukhnajmi commented Dec 17, 2018

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
Copy link

@vadzim-revolist vadzim-revolist commented Jan 9, 2019

+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
Copy link

@aheninger aheninger commented Jan 22, 2019

+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
Copy link

@eallenOP eallenOP commented Mar 19, 2019

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
Copy link

@JStickler JStickler commented May 30, 2019

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
Copy link

@krulik krulik commented Jun 10, 2019

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
Copy link

@arturpat arturpat commented Jul 8, 2019

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
Copy link

@barbogast barbogast commented Sep 3, 2019

image

😢

@molysgaard
Copy link

@molysgaard molysgaard commented Oct 3, 2019

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
Copy link

@arturpat arturpat commented Oct 3, 2019

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

@srozdilsky
Copy link

@srozdilsky srozdilsky commented Sep 25, 2020

+1
IMO, this is not just a feature request but a bug (missing basic functionality). I have always been frustrated by the lack of ability to do this in a github PR. I have never had an issue in other Peer Review platforms.

@dabrahams
Copy link

@dabrahams dabrahams commented Sep 30, 2020

For what it's worth, there's a project called ReviewNB that supports this feature for Jupyter Notebooks in GitHub. If someone could figure out how to make that work for all files, it would solve this problem.

@bw2
Copy link

@bw2 bw2 commented Oct 25, 2020

+1

@lupinitylabs
Copy link

@lupinitylabs lupinitylabs commented Oct 31, 2020

+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
Copy link

@okwme okwme commented Nov 23, 2020

+1

@Androz2091
Copy link

@Androz2091 Androz2091 commented Jan 3, 2021

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
Copy link

@ToddBradley ToddBradley commented Jan 5, 2021

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
Copy link

@chadm-sq chadm-sq commented Jan 22, 2021

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.

lazysoundsystem referenced this issue in UN-OCHA/common_design Jan 29, 2021
…al rhythm and reduce flow value for most compact display, add width and height attributes to svg icons
@bhrutledge
Copy link

@bhrutledge bhrutledge commented Feb 9, 2021

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

@bhrutledge
Copy link

@bhrutledge bhrutledge commented Feb 10, 2021

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
Copy link

@shadiramadan shadiramadan commented Feb 25, 2021

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

@shadiramadan
Copy link

@shadiramadan shadiramadan commented Feb 25, 2021

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

@SylvainTakerkart
Copy link

@SylvainTakerkart SylvainTakerkart commented Mar 16, 2021

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

@chadm-sq
Copy link

@chadm-sq chadm-sq commented Mar 16, 2021

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
Copy link

@tribbloid tribbloid commented Jun 14, 2021

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

@davidvincze
Copy link

@davidvincze davidvincze commented Jul 12, 2021

+1

@ililic
Copy link

@ililic ililic commented Jul 20, 2021

How has this been open since 2014 lol 💩

@Levi-Lesches
Copy link
Contributor

@Levi-Lesches Levi-Lesches commented Jul 21, 2021

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.

@harayuanwang
Copy link

@harayuanwang harayuanwang commented Jul 30, 2021

+1

@chadm-sq
Copy link

@chadm-sq chadm-sq commented Jul 30, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests