[Feature request] Use "--color-moved" diffing algorithm in PRs #9632
Replies: 16 comments 19 replies
-
|
Please do this. The one thing I miss most about phabricator is that it can differentiate between moved vs actually changed code. |
Beta Was this translation helpful? Give feedback.
-
|
Yup, now I'm discouraged to move code blocks into separate files, because the actual change info is lost with the moving of a code block. even though it's nicer in the long run. No one in my team does this in favor of clear PR's, but we do end up with long files for this reason. |
Beta Was this translation helpful? Give feedback.
-
|
(Crossposted to https://gist.github.com/0xdevalias/1245fe66ac6953d490114b417a0075e3 for posterity) Omg yes, please! This is one of my biggest pet peeves/code review slowdowns when performing large refactors to cleanup a legacy codebase. The following were some manual review notes/commands I added to a recent PR to assist others who were reviewing:
|
Beta Was this translation helpful? Give feedback.
-
|
Any news about this? |
Beta Was this translation helpful? Give feedback.
-
|
any news? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
As an alternative, you can use VS Code to review while highlighting moved code. It's available behind an experimental flag. It also works in githubs online version. So, simply press |
Beta Was this translation helpful? Give feedback.
-
|
Any news about this? |
Beta Was this translation helpful? Give feedback.
-
|
Also vote for this feature. Current Vscode is able to detect line move inside a file. But not so when functions are moved across files. @hediet |
Beta Was this translation helpful? Give feedback.
-
|
you know this isn't being prioritized because the squeaky wheel gets the oil and not enough wheels are squeaking for this. and the reason not enough wheels are squeaking for this is because the majority of developers are not that scrutinizing (line-by-line) when it comes to code review, so the introduction of this feature wouldn't change many developers user experience much if at all. |
Beta Was this translation helpful? Give feedback.
-
|
This would be a huge boon for code review. |
Beta Was this translation helpful? Give feedback.
-
|
I discovered it this week after using git for 10 years: https://blog.gitbutler.com/how-git-core-devs-configure-git/ . It makes a huge difference when reading a diff. |
Beta Was this translation helpful? Give feedback.
-
|
This doesn’t address the original problem directly, but might be useful if you’re in this situation: https://github.com/sageserpent-open/kineticMerge. The idea is to merge with awareness of code motion due to refactoring. Now that is really dealing with the next stage after a PR is reviewed and given the thumbs up, but you could run it with (I’m the author, BTW). |
Beta Was this translation helpful? Give feedback.
-
|
Come on, Github. Please... 🥺 |
Beta Was this translation helpful? Give feedback.
-
|
This would save a ton of time and make code review and refactors easier! I often comment across lines saying “these lines were moved but unchanged” but this doesn’t scale well at all |
Beta Was this translation helpful? Give feedback.
-
I'm nothing to do with GitHub (well, other than using it to host my own stuff), so I can't help with this feature request at all, but I would be interested to hear from the many participants on this thread as to whether they tried, and had any success with, using Kinetic Merge in The idea being to sit on the branch where code has been refactored (which presumably would be the branch being merged-back, so to speak, to the mainline in the PR). Kinetic Merge would be used to do this merge from a reversed view point, refreshing the refactoring branch with the latest changes from the mainline. (As an aside, I would do this anyway prior to raising a PR for a merge-back, because I want the PR to be purely for review and not for assistance in resolving merge conflicts or getting a build to succeed - that obligation is on me, not the reviewers.) Anyway, having the merge done as uncommitted means that Yes, the moved code is in a different place on the mainline, and that would confuse a standard diff / merge - but Kinetic Merge can cope with that, and what's more, can bring in edits to such moved code made on the mainline, so these edits will show up in the diff in the right place. I don't think Git's moved line detection can cope with edits to moved code, although I'm willing to be corrected on this. Now this isn't what was orginally asked for, but I'm trying to step back a bit and look at the overall problem here. Maybe this approach could help? Given I'm the author of said tool, I would certainly be keen to hear of any experiences if people do try it out. Probably best to raise tickets over in Kinetic Merge rather than subverting this discussion further with alien concepts. 😁 |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
PRs that move code around, even within the same function, show
nlines removed andnadded. One would assume this diff could be shown as a trivial "code move". This scales poorly when dealing with multiple function trivial code-moves.This also appears to make contributions on Github a bit misleading: moving code around may give the impression that a certain contributor makes huge number of additions and deletions to a repository, when in fact they didn't contribute to any functionality whatsoever.
As of now, git itself IS able to detect such changes: https://git-scm.com/docs/git-diff
Beta Was this translation helpful? Give feedback.
All reactions