Scott Chacon of Pro Git fame is writing about Git again: this time, with (yet another) take on how the company he helped build might be doing it wrong.

In How to do patch-based review with git range-diff, Chacon covers the ground on how to perform review in terms of versions of a branch, stuff Git developers have been doing for years. See my own primer for details on the workflow, especially with GitHub involvement. What’s particularly great about Chacon’s post for GitButler is its link to Why some of us like “interdiff” code review.

This blog post-né-Gist captures many of my own recent thoughts about GitHub:

• GitHub’s UI actively encourages suboptimal development technique¹. In practice, that means “diff soup” and “lack of solid tools for reviewers outside of the comment interface.”
• In particular, implicit relationships and information loss abound, which sucks for reviewer and future code spelunker.
• GitHub encourages branch- and merge- heavy thinking. These are not necessarily even the easy parts of Git! They can be for a solo developer just getting started, but in true distributed settings come with their own challenges.
• Interdiff reviewing requires more knowledge of Git than is typical or average (based on my own unscientific view of lots of colleagues), and thus would benefit more from UI help than typical branch and merge operations.

It is nice to have language to talk about this. I can just see myself writing “Please stop feeding me diff soup: I don’t need a feast, but I would like some seasoning.” (Accompanied, of course, by details on how to improve!)

PS Chacon’s article mentions that you’ll often need to note an original hash or find one in the reflog to compare the old branch version to the new branch version. For git range-diff superpowers, try using git range-diff @{u} @{push} @ to see what’s changed since you pushed.

Notes

Categories: Blog

Previous Next

Back to posts