On Mon, Sep 23, 2024 at 2:44 PM Kristoffer Haugsbakk
<kristofferhaugsbakk@xxxxxxxxxxxx> wrote:
> On Mon, Sep 23, 2024, at 19:51, Eric Sunshine wrote:
> > Depending upon how dramatically the patch series changes from one
> > version to the next, the range-diff may end up being unreadable
> > gobbledygook, in which case you may instead want to include an
> > interdiff ("git format-patch --interdiff").
>
> What’s the benefit of interdiff in that case? Neither
> git-format-patch(1) nor git-range-diff(1) seems to discuss what the
> differences between these two are.
An interdiff is just a plain diff. If you have branch (or tag) "v1"
which is the original version of a patch series, and "v2" which is the
reroll of the series, then interdiff is simply:
git diff v1 v2
Thus, it shows the difference between the final state of the code at
v1 and the state at v2. Interdiffs are easy to read because they are
just diffs. However, because they are only showing differences in file
content, they don't show changes to commit messages or new or removed
or reordered patches in a series.
A range-diff is a diff-of-diffs. It is very, very roughly similar to this:
git format-patch -o v1-patches <common-base>..v1
git format-patch -o v2-patches <common-base>..v2
some-diff-dir-command v1-patches v2-patches
It shows the diff of the patches themselves, including changes to
commit messages and changes to changes, as well as inserted and
removed and reordered patches.
Range-diffs tend to be a good deal more difficult to read (at least at
first) but help show the evolution of the _patch series_ itself
between versions, whereas interdiffs show only the evolution of the
_code_ between versions. As a reviewer, if you're primarily interested
in how the code evolved, then interdiffs are much more easily
digested, but most reviewers are also interested in the holistic
aspects of a patch series for which range-diffs are more helpful. I
periodically include both range-diff and interdiffs in my rerolls.
