A concept I feel ought to exist, but doesn't exist, in software development is the "diff diff". In other words, if there are two separate patches performing a similar function, I want to see the difference between those two patches. I've been thinking about this for years but I don't think I've ever seen it and I don't even know what word to use to describe it.
You could apply both patches and compare the results, but this is high-friction and doesn't work if the patches have different roots.
@mcc I don't know what powers it, but Gerrit has this capability to compare two different versions of a patch ("CL", ~pull request). It's a massive improvement over code-reviewed development on GitHub which I also do a ton of.
See here for example: https://dawn-review.googlesource.com/c/dawn/+/64620/1..3
This compares the 1st revision ("patchset") of the patch with the 3rd. As shown in the commit message diff, it's been rebased since the 1st revision (this happened automatically when merge automation "rebase and merge"d).
@mcc Each patchset is a git commit object. The final patchset is the actual commit that's now in the 'main' branch.
In the diff, red and green are changes in the actual patch (here, these happened in PS 2), and blue and yellow are changes in the same file that were not part of the patch (here, these happened in PS 3).
(For color blindness, I hope side-by-side diff mode is sufficient: removals (red/yellow) are always on the left; additions (green/blue) are always on the right.)
What I am trying to deal with at this second is comparing two PRs on Github that existed in the past, one of which no longer exists in git (it got squash merged, then the original branch was deleted) and the only record is on github. So this may be a situation there's nothing to be done because some of the data is lost lol :(
@mcc If you can figure out the commit hash, there's a chance it still exists. I don't know if or how often GitHub garbage collects, but it definitely doesn't happen immediately on deletion of a branch.
IMHO Gerrit is miles and miles better at code review than GitHub and Gitlab.
Also, it has good / useful keybindings so you can navigate a lot without leaving the keyboard.
@dneto@kainino0x@mcc I was "forced" to use Gerrit when working on Android/AOSP stuff and prefer Phabricator to Gerrit. But either is a vast improvement.
@mcc There’s a tool called interdiff but it does need the two diffs to be based on the same base. I have seen the name used for the concept as well, though possibly just as a function of being the most known tool.
@mcc
I use p4merge's 4-panel GUI to resolve git merge conflicts because it shows the difference between diffs more clearly (it shows the file @ merge base, each branch's diff applied in its own context, then the final attempted combination with toggles and full edit access if desired).
Sometimes it shows no conflicts when git says there were conflicts, so I suspect it's attempting the thing in your second paragraph in this specific context.
@mcc one of the most taxing jobs I ever had was as a debugger. Mainly, making sure all the other dev updates didn't clash with eachother and fix it if they did. I've never worked as a developer since that job .. people asks me why.
But, I can imagine something that does the job in a much better way. Particularly, it'd be nice for it to use language-specific analysis (as one sees in a modern ide) to highlight / annotate the meaningful differences.
@Sidneys1@mcc three way diff/merge was my immediate thought as well. I do this in Meld all the time to resolve conflicts between my changes and someone else's changes to a common base version.
Add comment