←back to thread

140 points Tomte | 1 comments | | HN request time: 0.203s | source
Show context
gnuvince ◴[] No.26288322[source]
Hijacking this topic to talk about something I've been thinking about lately: literate diffs.

I find that the order of diffs given by git is not optimized for helping a reviewer understand the change. Sometimes the order of files will not be in the most logical way; sometimes unrelated changes (e.g., a text editor removing blanks at the end of lines) create noise; etc.

I've been thinking that it would be interesting to have a tool where the author can take the diff of their commit(s), order them in a way that is conducive to understanding and explain each part of the diff. That'd be similar to having the author do a code walkthrough, but at the pace of the reader rather than the author.

replies(6): >>26288537 #>>26288793 #>>26288837 #>>26289067 #>>26289125 #>>26289821 #
1. geofft ◴[] No.26289067[source]
I would love if my VCS tool could also keep track of things like "This diff is the result of running sed -i s/this/that/g .py". I usually split out such mechanical changes anyway into a separate commit, but it would be clearer for reviewers to see that (most review tools show you the overall diff of the entire branch you want to merge by default, making you click further to see patch-by-patch changes), and it would also be easier for me* if the VCS could re-run the sed command when I rebased.

(An obvious next step is Coccinelle-style semantic patches, but let's start with sed!)