I’ve come around to this solution as well, but not because I find the diffs hard to read as such. Rather, it’s because I can do a much better job reviewing contemporary code (where adding a small feature often requires editing six files) if I have all my rich code navigation and debugging tools. Not sure what type this is in reality when looking at a JS patch? Slap a debugger there and find out. Concerned this code might be a performance regression? Why speculate when I can find out myself with pprof in twenty seconds. GitHub actually does a nice job making this trivial with code spaces, too.
Something I still feel is fundamentally lost from the Smalltalks and Common Lisps is the idea of the code as a living entity that is first-class alongside the running system, rather than simply the literal source of something other. Reviewing the way I just described is the only way you can in Smalltalk, so I think it’s been natural to get back into it.
This is one of the areas the web UI of (some) git forges are good, in my experience. For instance Azure DevOps allows you to click on a file in the PR diff view and that takes you to the full file view that also shows the diff (whether you want it split or unified). It is one of the things I miss on GitHub, where the best approximation seems to be to spam the arrows to expand the diff view up/down.
I’m not sure that I completely understand the author. Isn’t the “new” side of a split diff just the new code (and some empty gaps)?
I completely agree that checking out the code can be super useful a dn frequently do it. (Great for checking the called functions and things like “I don’t think this cast is necessary).
Isn’t the “new” side of a split diff just the new code (and some empty gaps)?
It is, but:
the code isn’t “live” — I can’t goto definition, move to a different file (which might or might have not been changed), and still see the diff on the right
empty gaps matter! I want to review code, I don’t want to review diff. There are some fancier diff algorithms working with syntax trees and what not, which could explain what exactly have changed and make diffs better, but that’s not what I need. For me, mark in the gutter which says “code in this area was changed” is more than enough, I am going to read the entire function anyway. What I need is just my usual view of the code, with all of the shortcuts and such. I don’t want the diff to be a centerpiece of my review process, it’s rather just one bit of context surrounding the code.
The “diff” in the title is a tongue-in-cheek — I don’t actually need a better diff, I need my normal view with reading code, just with diff shown to the side as a contextual info.
Is there a way you can hack around git reset so that you have the changes in the work tree but git still has master/main as HEAD? That way you would get gutter info without having to look at a diff.
Maybe I am misunderstanding, but isn’t $ git reset $(git merge-base HEAD main) from the post exactly that? The reason I have gutter info on the screenshot is exactly because I have unstaged changes in the working tree. But I also need the diff to see more context. And I don’t want to click on the gutter every time I want to see the diff, I want it to always be there.
Sssshhhhh! Don’t mention it out loud! Apple might remember that they made it screw it up again. They broke three way merges for a year or two last time that happened.
I’ve come around to this solution as well, but not because I find the diffs hard to read as such. Rather, it’s because I can do a much better job reviewing contemporary code (where adding a small feature often requires editing six files) if I have all my rich code navigation and debugging tools. Not sure what type this is in reality when looking at a JS patch? Slap a debugger there and find out. Concerned this code might be a performance regression? Why speculate when I can find out myself with pprof in twenty seconds. GitHub actually does a nice job making this trivial with code spaces, too.
Something I still feel is fundamentally lost from the Smalltalks and Common Lisps is the idea of the code as a living entity that is first-class alongside the running system, rather than simply the literal source of something other. Reviewing the way I just described is the only way you can in Smalltalk, so I think it’s been natural to get back into it.
This is one of the areas the web UI of (some) git forges are good, in my experience. For instance Azure DevOps allows you to click on a file in the PR diff view and that takes you to the full file view that also shows the diff (whether you want it split or unified). It is one of the things I miss on GitHub, where the best approximation seems to be to spam the arrows to expand the diff view up/down.
I’m not sure that I completely understand the author. Isn’t the “new” side of a split diff just the new code (and some empty gaps)?
I completely agree that checking out the code can be super useful a dn frequently do it. (Great for checking the called functions and things like “I don’t think this cast is necessary).
It is, but:
The “diff” in the title is a tongue-in-cheek — I don’t actually need a better diff, I need my normal view with reading code, just with diff shown to the side as a contextual info.
Semi-related little-know tip, while we are at it:
Add this to your
.gitconfigfor the times where you do look at rawgit diffoutput.Is there a way you can hack around
git resetso that you have the changes in the work tree butgitstill hasmaster/mainas HEAD? That way you would get gutter info without having to look at a diff.Maybe I am misunderstanding, but isn’t
$ git reset $(git merge-base HEAD main)from the post exactly that? The reason I have gutter info on the screenshot is exactly because I have unstaged changes in the working tree. But I also need the diff to see more context. And I don’t want to click on the gutter every time I want to see the diff, I want it to always be there.Ah, somehow I skimmed over that!
So … kinda like FileMerge.app’s diff maybe?
Sssshhhhh! Don’t mention it out loud! Apple might remember that they made it screw it up again. They broke three way merges for a year or two last time that happened.