blob: 9701c1e5fdd5a016c360b8102f0193dfa0fb90fb [file] [log] [blame]
'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>]
( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
This command shows the differences between two versions of a patch
message and the commit diff) is reasonably small compared to the
second commit range, with unmatched commits being inserted just after
all of their ancestors have been shown.
When the commit diffs differ, `git range-diff` recreates the
the *background* being red/green to make it easier to see e.g.
when there was a change in what exact lines were added.
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
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
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
This flag is passed to the `git log` program
(see linkgit: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>`.
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.
`git range-diff` also accepts the regular diff options (see
linkgit:git-diff[1]), most notably the `--color=[<when>]` and
`--no-color` options. These options are used when generating the "diff
diff options passed to `git log` when generating those patches.
The output of the `range-diff` command is subject to change. It is
be used across versions of Git to get a textually stable `range-diff`
(as opposed to something like the `--stable` option to
linkgit:git-patch-id[1]). There's also no equivalent of
linkgit:git-apply[1] for `range-diff`, the output is not intended to
be machine-readable.
This is particularly true when passing in diff options. Currently some
options like `--stat` can, as an emergent effect, produce output
that's quite useless in the context of `range-diff`. Future versions
of `range-diff` may learn to interpret such options in a manner
specific to `range-diff` (e.g. for `--stat` producing human-readable
output which summarizes how the diffstat changed).
This command uses the `diff.color.*` and `pager.range-diff` settings
(the latter is on by default).
See linkgit:git-config[1].
introduced by the rebase directly afterwards using:
A typical output of `git range-diff` would look like this:
2: f00dbal ! 3: decafe1 Describe a bug
@@ -1,3 +1,3 @@
Author: A U Thor <>
-TODO: Describe a bug
+Describe a bug
@@ -324,5 +324,6
This is expected.
-+What is unexpected is that it will also crash.
commit message of the 2nd commit as well its diff.
like regular `git diff`'s output. In addition, the first line (adding a
line (with a perfect match) is yellow like the commit header of `git
show`'s output, and the third line colors the old commit red, the new
one green and the rest like `git show`'s commit header.
To help with that, `range` uses the `--dual-color` mode by default. In
prefix the lines with -/+ markers that have their *background* red or
unrelated patch has been added between two iterations of the same patch
fixed-cost entries for wholesale deletes/adds.
Example: Let commits `1--2` be the first iteration of a patch series and
`A--C` the second iteration. Let's assume that `A` is a cherry-pick of
`2,` and `C` is a cherry-pick of `1` but with a small modification (say,
1 A
2 B
1 A
2 --------' B
`C` could be explained using `1`, but that comes at some cost c>0
because of the modification:
1 ----. A
| /
2 ----+---' B
`----- C
cost bipartite matching; `1` is matched to `C` at some cost, etc. The
on both sides:
1 ----. A
| /
2 ----+---' B
o `----- C
o o
o o
The cost of an edge `o--C` is the size of `C`'s diff, modified by a
`o--o` is free. The fudge factor is necessary because even if `1` and
`C` have nothing in common, they may still share a few empty lines and
such, possibly making the assignment `1--C`, `o--o` slightly cheaper
than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the
uses an implementation of the Jonker-Volgenant algorithm to solve the
assignment problem, which has cubic runtime complexity. The matching
found in this case will look like this:
1 ----. A
| /
2 ----+---' B
o -' `----- C
o ---------- o
o ---------- o
Part of the linkgit:git[1] suite