Documentation/git-range-diff.txt - jrn/git - Git at Google

 git-range-diff(1)
 =================

 NAME
 ----
 git-range-diff - Compare two commit ranges (e.g. two versions of a branch)

 SYNOPSIS
 --------
 [verse]
 '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).

 In the presence of `<path>` arguments, these commit ranges are limited
 accordingly.

 To that end, it first finds pairs of commits from both commit ranges
 that correspond with each other. Two commits are said to correspond when
 the diff between their patches (i.e. the author information, the commit
 message and the commit diff) is reasonably small compared to the
 patches' size. See ``Algorithm`` below for details.

 Finally, the list of matching commits is shown in the order of the
 second commit range, with unmatched commits being inserted just after
 all of their ancestors have been shown.

 There are three ways to specify the commit ranges:

 - `<range1> <range2>`: Either commit range can be of the form
   `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES`
   in linkgit: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-color::
 	When 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 of 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 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>`.

 <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.

 `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
 between patches", i.e. to compare the author, commit message and diff of
 corresponding old/new commits. There is currently no means to tweak most of the
 diff options passed to `git log` when generating those patches.

 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
 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).

 CONFIGURATION
 -------------
 This command uses the `diff.color.*` and `pager.range-diff` settings
 (the latter is on by default).
 See linkgit: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} @
 ------------


 A typical output of `git range-diff` would look like this:

 ------------
 -:  ------- > 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 <author@example.com>

     -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
 ------------

 In this example, there are 3 old and 3 new commits, where the developer
 removed the 3rd, added a new one before the first two, and modified the
 commit message of the 2nd commit as well as its diff.

 When the output goes to a terminal, it is color-coded by default, just
 like regular `git diff`'s output. In addition, the first line (adding a
 commit) is green, the last line (deleting a commit) is red, the second
 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.

 A naive color-coded diff of diffs is actually a bit hard to read,
 though, as it colors the entire lines red or green. The line that added
 "What is unexpected" in the old commit, for example, is completely red,
 even if the intent of the old commit was to add something.

 To help with that, `range` uses the `--dual-color` mode by default. In
 this mode, the diff of diffs will retain the original diff colors, and
 prefix the lines with -/+ markers that have their *background* red or
 green, to make it more obvious that they describe how the diff itself
 changed.


 Algorithm
 ---------

 The general idea is this: we generate a cost matrix between the commits
 in both commit ranges, then solve the least-cost assignment.

 The cost matrix is populated thusly: for each pair of commits, both
 diffs are generated and the "diff of diffs" is generated, with 3 context
 lines, then the number of lines in that diff is used as cost.

 To avoid false positives (e.g. when a patch has been removed, and an
 unrelated patch has been added between two iterations of the same patch
 series), the cost matrix is extended to allow for that, by adding
 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,
 a fixed typo). Visualize the commits as a bipartite graph:

 ------------
     1            A

     2            B

 		 C
 ------------

 We are looking for a "best" explanation of the new series in terms of
 the old one. We can represent an "explanation" as an edge in the graph:


 ------------
     1            A
 	       /
     2 --------'  B

 		 C
 ------------

 This explanation comes for "free" because there was no change. Similarly
 `C` could be explained using `1`, but that comes at some cost c>0
 because of the modification:

 ------------
     1 ----.      A
 	  |    /
     2 ----+---'  B
 	  |
 	  `----- C
 	  c>0
 ------------

 In mathematical terms, what we are looking for is some sort of a minimum
 cost bipartite matching; `1` is matched to `C` at some cost, etc. The
 underlying graph is in fact a complete bipartite graph; the cost we
 associate with every edge is the size of the diff between the two
 commits' patches. To explain also new commits, we introduce dummy nodes
 on both sides:

 ------------
     1 ----.      A
 	  |    /
     2 ----+---'  B
 	  |
     o     `----- C
 	  c>0
     o            o

     o            o
 ------------

 The cost of an edge `o--C` is the size of `C`'s diff, modified by a
 fudge factor that should be smaller than 100%. The cost of an edge
 `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
 fudge factor we require a much larger common part to consider patches as
 corresponding.

 The overall time needed to compute this algorithm is the time needed to
 compute n+m commit diffs and then n*m diffs of patches, plus the time
 needed to compute the least-cost assignment between n and m diffs. Git
 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
 	  c>0
     o ---------- o

     o ---------- o
 ------------


 SEE ALSO
 --------
 linkgit:git-log[1]

 GIT
 ---
 Part of the linkgit:git[1] suite
	git-range-diff(1)
	=================

	NAME
	----
	git-range-diff - Compare two commit ranges (e.g. two versions of a branch)

	SYNOPSIS
	--------
	[verse]
	'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).

	In the presence of `<path>` arguments, these commit ranges are limited
	accordingly.

	To that end, it first finds pairs of commits from both commit ranges
	that correspond with each other. Two commits are said to correspond when
	the diff between their patches (i.e. the author information, the commit
	message and the commit diff) is reasonably small compared to the
	patches' size. See ``Algorithm`` below for details.

	Finally, the list of matching commits is shown in the order of the
	second commit range, with unmatched commits being inserted just after
	all of their ancestors have been shown.

	There are three ways to specify the commit ranges:

	- `<range1> <range2>`: Either commit range can be of the form
	`<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES`
	in linkgit: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-color::
	When 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 of 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 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>`.

	<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.

	`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
	between patches", i.e. to compare the author, commit message and diff of
	corresponding old/new commits. There is currently no means to tweak most of the
	diff options passed to `git log` when generating those patches.

	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
	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).

	CONFIGURATION
	-------------
	This command uses the `diff.color.*` and `pager.range-diff` settings
	(the latter is on by default).
	See linkgit: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} @
	------------


	A typical output of `git range-diff` would look like this:

	------------
	-: ------- > 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 <author@example.com>

	-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
	------------

	In this example, there are 3 old and 3 new commits, where the developer
	removed the 3rd, added a new one before the first two, and modified the
	commit message of the 2nd commit as well as its diff.

	When the output goes to a terminal, it is color-coded by default, just
	like regular `git diff`'s output. In addition, the first line (adding a
	commit) is green, the last line (deleting a commit) is red, the second
	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.

	A naive color-coded diff of diffs is actually a bit hard to read,
	though, as it colors the entire lines red or green. The line that added
	"What is unexpected" in the old commit, for example, is completely red,
	even if the intent of the old commit was to add something.

	To help with that, `range` uses the `--dual-color` mode by default. In
	this mode, the diff of diffs will retain the original diff colors, and
	prefix the lines with -/+ markers that have their background red or
	green, to make it more obvious that they describe how the diff itself
	changed.


	Algorithm
	---------

	The general idea is this: we generate a cost matrix between the commits
	in both commit ranges, then solve the least-cost assignment.

	The cost matrix is populated thusly: for each pair of commits, both
	diffs are generated and the "diff of diffs" is generated, with 3 context
	lines, then the number of lines in that diff is used as cost.

	To avoid false positives (e.g. when a patch has been removed, and an
	unrelated patch has been added between two iterations of the same patch
	series), the cost matrix is extended to allow for that, by adding
	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,
	a fixed typo). Visualize the commits as a bipartite graph:

	------------
	1 A

	2 B

	C
	------------

	We are looking for a "best" explanation of the new series in terms of
	the old one. We can represent an "explanation" as an edge in the graph:


	------------
	1 A
	/
	2 --------' B

	C
	------------

	This explanation comes for "free" because there was no change. Similarly
	`C` could be explained using `1`, but that comes at some cost c>0
	because of the modification:

	------------
	1 ----. A
	\| /
	2 ----+---' B
	\|
	`----- C
	c>0
	------------

	In mathematical terms, what we are looking for is some sort of a minimum
	cost bipartite matching; `1` is matched to `C` at some cost, etc. The
	underlying graph is in fact a complete bipartite graph; the cost we
	associate with every edge is the size of the diff between the two
	commits' patches. To explain also new commits, we introduce dummy nodes
	on both sides:

	------------
	1 ----. A
	\| /
	2 ----+---' B
	\|
	o `----- C
	c>0
	o o

	o o
	------------

	The cost of an edge `o--C` is the size of `C`'s diff, modified by a
	fudge factor that should be smaller than 100%. The cost of an edge
	`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
	fudge factor we require a much larger common part to consider patches as
	corresponding.

	The overall time needed to compute this algorithm is the time needed to
	compute n+m commit diffs and then n*m diffs of patches, plus the time
	needed to compute the least-cost assignment between n and m diffs. Git
	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
	c>0
	o ---------- o

	o ---------- o
	------------


	SEE ALSO
	--------
	linkgit:git-log[1]

	GIT
	---
	Part of the linkgit:git[1] suite