6 git-range-diff - Compare two commit ranges (e.g. two versions of a branch)
11 'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>]
12 [--no-dual-color] [--creation-factor=<factor>]
13 [--left-only | --right-only]
14 ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
19 This command shows the differences between two versions of a patch
20 series, or more generally, two commit ranges (ignoring merge commits).
22 To that end, it first finds pairs of commits from both commit ranges
23 that correspond with each other. Two commits are said to correspond when
24 the diff between their patches (i.e. the author information, the commit
25 message and the commit diff) is reasonably small compared to the
26 patches' size. See ``Algorithm`` below for details.
28 Finally, the list of matching commits is shown in the order of the
29 second commit range, with unmatched commits being inserted just after
30 all of their ancestors have been shown.
32 There are three ways to specify the commit ranges:
34 - `<range1> <range2>`: Either commit range can be of the form
35 `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES`
36 in linkgit:gitrevisions[7] for more details.
38 - `<rev1>...<rev2>`. This is equivalent to
39 `<rev2>..<rev1> <rev1>..<rev2>`.
41 - `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1>
47 When the commit diffs differ, `git range-diff` recreates the
48 original diffs' coloring, and adds outer -/+ diff markers with
49 the *background* being red/green to make it easier to see e.g.
50 when there was a change in what exact lines were added.
52 Additionally, the commit diff lines that are only present in the first commit
53 range are shown "dimmed" (this can be overridden using the `color.diff.<slot>`
54 config setting where `<slot>` is one of `contextDimmed`, `oldDimmed` and
55 `newDimmed`), and the commit diff lines that are only present in the second
56 commit range are shown in bold (which can be overridden using the config
57 settings `color.diff.<slot>` with `<slot>` being one of `contextBold`,
58 `oldBold` or `newBold`).
60 This is known to `range-diff` as "dual coloring". Use `--no-dual-color`
61 to revert to color all lines according to the outer diff markers
62 (and completely ignore the inner diff when it comes to color).
64 --creation-factor=<percent>::
65 Set the creation/deletion cost fudge factor to `<percent>`.
66 Defaults to 60. Try a larger value if `git range-diff` erroneously
67 considers a large change a total rewrite (deletion of one commit
68 and addition of another), and a smaller one in the reverse case.
69 See the ``Algorithm`` section below for an explanation why this is
73 Suppress commits that are missing from the first specified range
74 (or the "left range" when using the `<rev1>...<rev2>` format).
77 Suppress commits that are missing from the second specified range
78 (or the "right range" when using the `<rev1>...<rev2>` format).
80 --[no-]notes[=<ref>]::
81 This flag is passed to the `git log` program
82 (see linkgit:git-log[1]) that generates the patches.
85 Compare the commits specified by the two ranges, where
86 `<range1>` is considered an older version of `<range2>`.
89 Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`.
91 <base> <rev1> <rev2>::
92 Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`.
93 Note that `<base>` does not need to be the exact branch point
94 of the branches. Example: after rebasing a branch `my-topic`,
95 `git range-diff my-topic@{u} my-topic@{1} my-topic` would
96 show the differences introduced by the rebase.
98 `git range-diff` also accepts the regular diff options (see
99 linkgit:git-diff[1]), most notably the `--color=[<when>]` and
100 `--no-color` options. These options are used when generating the "diff
101 between patches", i.e. to compare the author, commit message and diff of
102 corresponding old/new commits. There is currently no means to tweak most of the
103 diff options passed to `git log` when generating those patches.
108 The output of the `range-diff` command is subject to change. It is
109 intended to be human-readable porcelain output, not something that can
110 be used across versions of Git to get a textually stable `range-diff`
111 (as opposed to something like the `--stable` option to
112 linkgit:git-patch-id[1]). There's also no equivalent of
113 linkgit:git-apply[1] for `range-diff`, the output is not intended to
116 This is particularly true when passing in diff options. Currently some
117 options like `--stat` can, as an emergent effect, produce output
118 that's quite useless in the context of `range-diff`. Future versions
119 of `range-diff` may learn to interpret such options in a manner
120 specific to `range-diff` (e.g. for `--stat` producing human-readable
121 output which summarizes how the diffstat changed).
125 This command uses the `diff.color.*` and `pager.range-diff` settings
126 (the latter is on by default).
127 See linkgit:git-config[1].
133 When a rebase required merge conflicts to be resolved, compare the changes
134 introduced by the rebase directly afterwards using:
137 $ git range-diff @{u} @{1} @
141 A typical output of `git range-diff` would look like this:
144 -: ------- > 1: 0ddba11 Prepare for the inevitable!
145 1: c0debee = 2: cab005e Add a helpful message at the start
146 2: f00dbal ! 3: decafe1 Describe a bug
148 Author: A U Thor <author@example.com>
150 -TODO: Describe a bug
155 -+What is unexpected is that it will also crash.
156 ++Unexpectedly, it also crashes. This is a bug, and the jury is
157 ++still out there how to fix it best. See ticket #314 for details.
160 3: bedead < -: ------- TO-UNDO
163 In this example, there are 3 old and 3 new commits, where the developer
164 removed the 3rd, added a new one before the first two, and modified the
165 commit message of the 2nd commit as well its diff.
167 When the output goes to a terminal, it is color-coded by default, just
168 like regular `git diff`'s output. In addition, the first line (adding a
169 commit) is green, the last line (deleting a commit) is red, the second
170 line (with a perfect match) is yellow like the commit header of `git
171 show`'s output, and the third line colors the old commit red, the new
172 one green and the rest like `git show`'s commit header.
174 A naive color-coded diff of diffs is actually a bit hard to read,
175 though, as it colors the entire lines red or green. The line that added
176 "What is unexpected" in the old commit, for example, is completely red,
177 even if the intent of the old commit was to add something.
179 To help with that, `range` uses the `--dual-color` mode by default. In
180 this mode, the diff of diffs will retain the original diff colors, and
181 prefix the lines with -/+ markers that have their *background* red or
182 green, to make it more obvious that they describe how the diff itself
189 The general idea is this: we generate a cost matrix between the commits
190 in both commit ranges, then solve the least-cost assignment.
192 The cost matrix is populated thusly: for each pair of commits, both
193 diffs are generated and the "diff of diffs" is generated, with 3 context
194 lines, then the number of lines in that diff is used as cost.
196 To avoid false positives (e.g. when a patch has been removed, and an
197 unrelated patch has been added between two iterations of the same patch
198 series), the cost matrix is extended to allow for that, by adding
199 fixed-cost entries for wholesale deletes/adds.
201 Example: Let commits `1--2` be the first iteration of a patch series and
202 `A--C` the second iteration. Let's assume that `A` is a cherry-pick of
203 `2,` and `C` is a cherry-pick of `1` but with a small modification (say,
204 a fixed typo). Visualize the commits as a bipartite graph:
214 We are looking for a "best" explanation of the new series in terms of
215 the old one. We can represent an "explanation" as an edge in the graph:
226 This explanation comes for "free" because there was no change. Similarly
227 `C` could be explained using `1`, but that comes at some cost c>0
228 because of the modification:
239 In mathematical terms, what we are looking for is some sort of a minimum
240 cost bipartite matching; `1` is matched to `C` at some cost, etc. The
241 underlying graph is in fact a complete bipartite graph; the cost we
242 associate with every edge is the size of the diff between the two
243 commits' patches. To explain also new commits, we introduce dummy nodes
258 The cost of an edge `o--C` is the size of `C`'s diff, modified by a
259 fudge factor that should be smaller than 100%. The cost of an edge
260 `o--o` is free. The fudge factor is necessary because even if `1` and
261 `C` have nothing in common, they may still share a few empty lines and
262 such, possibly making the assignment `1--C`, `o--o` slightly cheaper
263 than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the
264 fudge factor we require a much larger common part to consider patches as
267 The overall time needed to compute this algorithm is the time needed to
268 compute n+m commit diffs and then n*m diffs of patches, plus the time
269 needed to compute the least-cost assignment between n and m diffs. Git
270 uses an implementation of the Jonker-Volgenant algorithm to solve the
271 assignment problem, which has cubic runtime complexity. The matching
272 found in this case will look like this:
293 Part of the linkgit:git[1] suite
projects / git / blob