Quickly review changed methods and functions in your pull requests
github.com
github.com
IMHO diff-based code review creates distorted incentives. Moving large pieces of code around feels harder to review, and adding an extra line or two feels easier to review. In the long term, this drives codebases in the wrong direction. (That 900-line method got there through hundreds of innocuous-looking PRs.)
I hope eventually we get tools that make refactorings easy to review. I don't know what that would look like, or how well this can be done in today's languages, but there's room for improvement.
For example, if you moved a function 50 lines down and changed a string variable in that function, you'll be able to review and discuss the code changes like so:
Semantic changes
- Moved function FOO with public scope 50 lines down
- Updated string variable FOO with public scope in function FOO
Change impact - Moving function FOO 50 lines down does not change its scope.
- Lines 56 and 30 in files X and Y in repositories Q and Z, reference the BAR variable.
- Open pull request #35, contains FOO function changes as well.
- Active releases 1.x and 2.x do not have these changes.
The basic idea is, instead of only being able to review and comment on the lines changed, I fully expect us to be able to discuss their impact as well.I very often clone repos just so that I can open the code in an IDE, CTRL+Click a method and jump to its definition. It would be neat if Github had IDE-like features (but without becoming a platform for editing--just viewing!)
It would be awesome to hear a timeline for rolling this out to more languages, especially Python.
Our master plan at https://sourcegraph.com/plan describes what we're building on top of these basic "code intelligence" primitives, to help developers in all of their dev tools (not just GitHub), in all of their workflow, and in companies that have lots of code. And just like GitHub, we let people use these things for free on open-source so they can see how useful they are.
If anyone at GitHub is reading this, the dropdown cannot be keyboard navigated because the dropdown doesn't scroll with the focus.
EDIT: Actually, [0] mentions =L, which seems to work flawlessly. Hacking on an option to take the selected region instead of manually specifying file and lines is easy. Alternatively, magit-blame lets you look at a specific change's commit.