NAME
git-range-diff - Compare two commit ranges (e.g. two versions of a branch)SYNOPSIS
git range-diff [--color=[<when>]] [--no-color] [<diff-options>] [--no-dual-color] [--creation-factor=<factor>] [--left-only | --right-only] ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> ) [[--] <path>...]
DESCRIPTION
This command shows the differences between two versions of a patch series, or more generally, two commit ranges (ignoring merge commits).•<range1> <range2>:
Either commit range can be of the form <base>..<rev>,
<rev>^! or <rev>^-<n>. See SPECIFYING
RANGES in gitrevisions(7) for more details.
•<rev1>...<rev2>.
This is equivalent to <rev2>..<rev1>
<rev1>..<rev2>.
•<base> <rev1>
<rev2>: This is equivalent to <base>..<rev1>
<base>..<rev2>.
OPTIONS
--no-dual-colorWhen the commit diffs differ, ‘git
range-diff` recreates the original diffs’ coloring, and adds outer -/+
diff markers with the background being red/green to make it easier to
see e.g. when there was a change in what exact lines were added.
Additionally, the commit diff lines that are only present in the first commit
range are shown "dimmed" (this can be overridden using the
color.diff.<slot> config setting where <slot> is one
of contextDimmed, oldDimmed and newDimmed), and the
commit diff lines that are only present in the second commit range are shown
in bold (which can be overridden using the config settings
color.diff.<slot> with <slot> being one of
contextBold, oldBold or newBold).
This is known to range-diff as "dual coloring". Use
--no-dual-color to revert to color all lines according to the outer
diff markers (and completely ignore the inner diff when it comes to
color).
--creation-factor=<percent>
Set the creation/deletion cost fudge factor to
<percent>. Defaults to 60. Try a larger value if git
range-diff erroneously considers a large change a total rewrite (deletion
of one commit and addition of another), and a smaller one in the reverse case.
See the ``Algorithm`` section below for an explanation why this is
needed.
--left-only
Suppress commits that are missing from the
first specified range (or the "left range" when using the
<rev1>...<rev2> format).
--right-only
Suppress commits that are missing from the
second specified range (or the "right range" when using the
<rev1>...<rev2> format).
--[no-]notes[=<ref>]
This flag is passed to the git log
program (see git-log(1)) that generates the patches.
<range1> <range2>
Compare the commits specified by the two
ranges, where <range1> is considered an older version of
<range2>.
<rev1>...<rev2>
Equivalent to passing
<rev2>..<rev1> and <rev1>..<rev2>.
<base> <rev1> <rev2>
Equivalent to passing
<base>..<rev1> and <base>..<rev2>. Note
that <base> does not need to be the exact branch point of the
branches. Example: after rebasing a branch my-topic, git range-diff
my-topic@{u} my-topic@{1} my-topic would show the differences introduced
by the rebase.
OUTPUT STABILITY
The output of the range-diff command is subject to change. It is intended to be human-readable porcelain output, not something that can be used across versions of Git to get a textually stable range-diff (as opposed to something like the --stable option to git-patch-id(1)). There’s also no equivalent of git-apply(1) for range-diff, the output is not intended to be machine-readable.CONFIGURATION
This command uses the diff.color.* and pager.range-diff settings (the latter is on by default). See git-config(1).EXAMPLES
When a rebase required merge conflicts to be resolved, compare the changes introduced by the rebase directly afterwards using:$ git range-diff @{u} @{1} @
-: ------- > 1: 0ddba11 Prepare for the inevitable! 1: c0debee = 2: cab005e Add a helpful message at the start 2: f00dbal ! 3: decafe1 Describe a bug @@ -1,3 +1,3 @@ Author: A U Thor <[email protected]> -TODO: Describe a bug +Describe a bug @@ -324,5 +324,6 This is expected. -+What is unexpected is that it will also crash. ++Unexpectedly, it also crashes. This is a bug, and the jury is ++still out there how to fix it best. See ticket #314 for details. Contact 3: bedead < -: ------- TO-UNDO
ALGORITHM
The general idea is this: we generate a cost matrix between the commits in both commit ranges, then solve the least-cost assignment.1 A 2 B C
1 A / 2 --------' B C
1 ----. A | / 2 ----+---' B | `----- C c>0
1 ----. A | / 2 ----+---' B | o `----- C c>0 o o o o
1 ----. A | / 2 ----+---' B .--+-----' o -' `----- C c>0 o ---------- o o ---------- o
SEE ALSO
git-log(1)GIT
Part of the git(1) suite02/28/2023 | Git 2.39.2 |