Given two version (old and new) of a Git change (i.e., individual commit or patch series from a pull request) it produces a diff that is actually useful for reviewing purposes, assuming you've already reviewed the old version of the change.
It's sort of like `git range-diff`, but where `git range-diff` produces a "diff of diffs" that is very hard to impossible to read, this tool gives you a direct diff between old and new versions, but filters out any irrelevant changes that were introduced because the author rebased on a more recent version of the target branch.
I hope that makes sense - I never know quite how to put it into words for somebody to understand who isn't intimately familiar with Git. It is very powerful though if you combine it with a minimal amount of setup e.g. for fetching all PR branches from a GitHub repository. I use it almost daily as part of my code review workflow.
I'm the author of DiffLens (https://www.difflens.com/). I initially built it for myself too (and use it everyday) and it's currently free for anyone to try. It's an attempt to use abstract syntax trees to make diffs more readable. Happy to see another diff project here!
This sounds very cool! I recently moved from a FAANG company to a smaller one, and I'm _really_ missing the functionality their development tools provided (including this, which I agree is fantastic and sorely missing from the core GitHub experience).
Maybe you can put a small example of code changes that illustrates this. The diagram helps but actual output based on a toy example would drive it home, I think.
Given two version (old and new) of a Git change (i.e., individual commit or patch series from a pull request) it produces a diff that is actually useful for reviewing purposes, assuming you've already reviewed the old version of the change.
It's sort of like `git range-diff`, but where `git range-diff` produces a "diff of diffs" that is very hard to impossible to read, this tool gives you a direct diff between old and new versions, but filters out any irrelevant changes that were introduced because the author rebased on a more recent version of the target branch.
I hope that makes sense - I never know quite how to put it into words for somebody to understand who isn't intimately familiar with Git. It is very powerful though if you combine it with a minimal amount of setup e.g. for fetching all PR branches from a GitHub repository. I use it almost daily as part of my code review workflow.