Open matthewlmcclure opened 10 years ago
IIUC this could only be doable from the raw view for files that have preview like Markdown.
Why do you think it wouldn't be doable for arbitrary files in the blob view?
Would be non-trivial to associate comments to sources lines that show a special preview from the preview, like HTML preview of Markdown files on URLs of type blob/master
as in your screenshot.
I'm interested in things like this, but the big question is: how do you transfer the comments if the file is changed, e.g. commented lines moved to another place? I don't think its computationally doable, only through heuristics.
Another possibility would be to show the comments only until the file is changed, but that could happen anytime for an unrelated reason, so it's not a very interesting possibility.
OK I understand what you're saying now. Yes I imagine that would be a challenge. Hopefully not an insurmountable one.
Showing the comments from the last commit only would be a easy solution. Plus, I think we shouldn't be seeing 2 year old comments which are probably now invalid anyway.
As for creating new comments, they could automatically be delegated to the last commit.
:+1:
I want this. :+1: I think the mechanism for keeping comments across commits could roughly be the way a good implementation of patch works: using fuzzy matching. There are several implementations for it in Google diff/match/patch here.
match_main(new_commit_text, old_line_text, old_line_location)
. If the line is not found, then the comment is "dangling" and either delete it or mark it for user action, depending on user preferences.It would also be nice to keep a complete comment history for the file, and to move comments between files when their commented lines are moved (does git provide this info?).
Documentation for match_main
is here. The research question here is determining acceptable values of diff_match_patch.Match_Threshold
, which determines the fuzziness of the text match, and diff_match_patch.Match_Distance
, which determines the fuzziness of the location match.
Another +1. I'm a Google Summer of Code mentor, and I'd like to do a general code review on my student's repo. This is the exact feature I need to do that.
Wow, this was requested 2 years ago and there is exactly no improvement on this yet!
This is the workflow I'm looking for:
Also it would be nice to make the jump to blob (shortcut key 'y') feature more obvious, maybe by adding a button for it in the UI.
Another 👍. This will be very helpful for reviewing papers and books.
I would appreciate this as well! +1
👍
👍
+1
+1
+1
👍
👍
+1
👍
Here's a workaround that involves creating an "empty" branch and then creating a pull request to merge the desired branch into the empty branch: http://astrofrog.github.io/blog/2013/04/10/how-to-conduct-a-full-code-review-on-github/
+1
Please don't reply to an issue just to say '+1': it sends a notification to everyone subscribed to the issue. Instead, just react to the issue's initial comment with the 👍 emoji.
+1
I'd like to leave a comment about the current state of the code on a given branch.
It seems that as of 2014-06-13, to leave a comment on a given line in a given blob view, I have to navigate to Blame and then to the commit that introduced the line, where I can comment on the added line in the commit view.
My comment will trigger notifications to repository watchers, to people I mention, and presumably to the commit's author, but the GitHub website doesn't surface the comment anywhere other than on that old commit. My guess is that it's unlikely that many people will find it.
I could create an Issue instead, but issues connote a need for resolution, whereas I'm merely trying to create a greater opportunity for valuable action via starting a conversation.
Instead, I'd like to comment directly from the blob view to start a conversation about a given area of the code. I'd like those conversations to be easily retrievable via search and browsing.
I'm imagining something like Google Docs's commenting, where I can comment on a particular part of a document, a conversation can follow, and eventually one of the participants can Resolve the conversation.
Maybe "Conversations" should become Issues or have a similar but separate browsable and searchable index.