|
| 1 | +git-range-diff(1) |
| 2 | +================== |
| 3 | + |
| 4 | +NAME |
| 5 | +---- |
| 6 | +git-range-diff - Compare two commit ranges (e.g. two versions of a branch) |
| 7 | + |
| 8 | +SYNOPSIS |
| 9 | +-------- |
| 10 | +[verse] |
| 11 | +'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>] |
| 12 | + [--dual-color] [--creation-factor=<factor>] |
| 13 | + ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> ) |
| 14 | + |
| 15 | +DESCRIPTION |
| 16 | +----------- |
| 17 | + |
| 18 | +This command shows the differences between two versions of a patch |
| 19 | +series, or more generally, two commit ranges (ignoring merges). |
| 20 | + |
| 21 | +To that end, it first finds pairs of commits from both commit ranges |
| 22 | +that correspond with each other. Two commits are said to correspond when |
| 23 | +the diff between their patches (i.e. the author information, the commit |
| 24 | +message and the commit diff) is reasonably small compared to the |
| 25 | +patches' size. See ``Algorithm` below for details. |
| 26 | + |
| 27 | +Finally, the list of matching commits is shown in the order of the |
| 28 | +second commit range, with unmatched commits being inserted just after |
| 29 | +all of their ancestors have been shown. |
| 30 | + |
| 31 | + |
| 32 | +OPTIONS |
| 33 | +------- |
| 34 | +--dual-color:: |
| 35 | + When the commit diffs differ, recreate the original diffs' |
| 36 | + coloring, and add outer -/+ diff markers with the *background* |
| 37 | + being red/green to make it easier to see e.g. when there was a |
| 38 | + change in what exact lines were added. |
| 39 | + |
| 40 | +--creation-factor=<percent>:: |
| 41 | + Set the creation/deletion cost fudge factor to `<percent>`. |
| 42 | + Defaults to 60. Try a larger value if `git range-diff` erroneously |
| 43 | + considers a large change a total rewrite (deletion of one commit |
| 44 | + and addition of another), and a smaller one in the reverse case. |
| 45 | + See the ``Algorithm`` section below for an explanation why this is |
| 46 | + needed. |
| 47 | + |
| 48 | +<range1> <range2>:: |
| 49 | + Compare the commits specified by the two ranges, where |
| 50 | + `<range1>` is considered an older version of `<range2>`. |
| 51 | + |
| 52 | +<rev1>...<rev2>:: |
| 53 | + Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`. |
| 54 | + |
| 55 | +<base> <rev1> <rev2>:: |
| 56 | + Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`. |
| 57 | + Note that `<base>` does not need to be the exact branch point |
| 58 | + of the branches. Example: after rebasing a branch `my-topic`, |
| 59 | + `git range-diff my-topic@{u} my-topic@{1} my-topic` would |
| 60 | + show the differences introduced by the rebase. |
| 61 | + |
| 62 | +`git range-diff` also accepts the regular diff options (see |
| 63 | +linkgit:git-diff[1]), most notably the `--color=[<when>]` and |
| 64 | +`--no-color` options. These options are used when generating the "diff |
| 65 | +between patches", i.e. to compare the author, commit message and diff of |
| 66 | +corresponding old/new commits. There is currently no means to tweak the |
| 67 | +diff options passed to `git log` when generating those patches. |
| 68 | + |
| 69 | + |
| 70 | +CONFIGURATION |
| 71 | +------------- |
| 72 | +This command uses the `diff.color.*` and `pager.range-diff` settings |
| 73 | +(the latter is on by default). |
| 74 | +See linkgit:git-config[1]. |
| 75 | + |
| 76 | + |
| 77 | +EXAMPLES |
| 78 | +-------- |
| 79 | + |
| 80 | +When a rebase required merge conflicts to be resolved, compare the changes |
| 81 | +introduced by the rebase directly afterwards using: |
| 82 | + |
| 83 | +------------ |
| 84 | +$ git range-diff @{u} @{1} @ |
| 85 | +------------ |
| 86 | + |
| 87 | + |
| 88 | +A typical output of `git range-diff` would look like this: |
| 89 | + |
| 90 | +------------ |
| 91 | +-: ------- > 1: 0ddba11 Prepare for the inevitable! |
| 92 | +1: c0debee = 2: cab005e Add a helpful message at the start |
| 93 | +2: f00dbal ! 3: decafe1 Describe a bug |
| 94 | + @@ -1,3 +1,3 @@ |
| 95 | + Author: A U Thor < [email protected]> |
| 96 | + |
| 97 | + -TODO: Describe a bug |
| 98 | + +Describe a bug |
| 99 | + @@ -324,5 +324,6 |
| 100 | + This is expected. |
| 101 | + |
| 102 | + -+What is unexpected is that it will also crash. |
| 103 | + ++Unexpectedly, it also crashes. This is a bug, and the jury is |
| 104 | + ++still out there how to fix it best. See ticket #314 for details. |
| 105 | + |
| 106 | + Contact |
| 107 | +3: bedead < -: ------- TO-UNDO |
| 108 | +------------ |
| 109 | + |
| 110 | +In this example, there are 3 old and 3 new commits, where the developer |
| 111 | +removed the 3rd, added a new one before the first two, and modified the |
| 112 | +commit message of the 2nd commit as well its diff. |
| 113 | + |
| 114 | +When the output goes to a terminal, it is color-coded by default, just |
| 115 | +like regular `git diff`'s output. In addition, the first line (adding a |
| 116 | +commit) is green, the last line (deleting a commit) is red, the second |
| 117 | +line (with a perfect match) is yellow like the commit header of `git |
| 118 | +show`'s output, and the third line colors the old commit red, the new |
| 119 | +one green and the rest like `git show`'s commit header. |
| 120 | + |
| 121 | +The color-coded diff is actually a bit hard to read, though, as it |
| 122 | +colors the entire lines red or green. The line that added "What is |
| 123 | +unexpected" in the old commit, for example, is completely red, even if |
| 124 | +the intent of the old commit was to add something. |
| 125 | + |
| 126 | +To help with that, use the `--dual-color` mode. In this mode, the diff |
| 127 | +of diffs will retain the original diff colors, and prefix the lines with |
| 128 | +-/+ markers that have their *background* red or green, to make it more |
| 129 | +obvious that they describe how the diff itself changed. |
| 130 | + |
| 131 | + |
| 132 | +Algorithm |
| 133 | +--------- |
| 134 | + |
| 135 | +The general idea is this: we generate a cost matrix between the commits |
| 136 | +in both commit ranges, then solve the least-cost assignment. |
| 137 | + |
| 138 | +To avoid false positives (e.g. when a patch has been removed, and an |
| 139 | +unrelated patch has been added between two iterations of the same patch |
| 140 | +series), the cost matrix is extended to allow for that, by adding |
| 141 | +fixed-cost entries for wholesale deletes/adds. |
| 142 | + |
| 143 | +Example: Let commits `1--2` be the first iteration of a patch series and |
| 144 | +`A--C` the second iteration. Let's assume that `A` is a cherry-pick of |
| 145 | +`2,` and `C` is a cherry-pick of `1` but with a small modification (say, |
| 146 | +a fixed typo). Visualize the commits as a bipartite graph: |
| 147 | + |
| 148 | +------------ |
| 149 | + 1 A |
| 150 | + |
| 151 | + 2 B |
| 152 | + |
| 153 | + C |
| 154 | +------------ |
| 155 | + |
| 156 | +We are looking for a "best" explanation of the new series in terms of |
| 157 | +the old one. We can represent an "explanation" as an edge in the graph: |
| 158 | + |
| 159 | + |
| 160 | +------------ |
| 161 | + 1 A |
| 162 | + / |
| 163 | + 2 --------' B |
| 164 | + |
| 165 | + C |
| 166 | +------------ |
| 167 | + |
| 168 | +This explanation comes for "free" because there was no change. Similarly |
| 169 | +`C` could be explained using `1`, but that comes at some cost c>0 |
| 170 | +because of the modification: |
| 171 | + |
| 172 | +------------ |
| 173 | + 1 ----. A |
| 174 | + | / |
| 175 | + 2 ----+---' B |
| 176 | + | |
| 177 | + `----- C |
| 178 | + c>0 |
| 179 | +------------ |
| 180 | + |
| 181 | +In mathematical terms, what we are looking for is some sort of a minimum |
| 182 | +cost bipartite matching; `1` is matched to `C` at some cost, etc. The |
| 183 | +underlying graph is in fact a complete bipartite graph; the cost we |
| 184 | +associate with every edge is the size of the diff between the two |
| 185 | +commits' patches. To explain also new commits, we introduce dummy nodes |
| 186 | +on both sides: |
| 187 | + |
| 188 | +------------ |
| 189 | + 1 ----. A |
| 190 | + | / |
| 191 | + 2 ----+---' B |
| 192 | + | |
| 193 | + o `----- C |
| 194 | + c>0 |
| 195 | + o o |
| 196 | + |
| 197 | + o o |
| 198 | +------------ |
| 199 | + |
| 200 | +The cost of an edge `o--C` is the size of `C`'s diff, modified by a |
| 201 | +fudge factor that should be smaller than 100%. The cost of an edge |
| 202 | +`o--o` is free. The fudge factor is necessary because even if `1` and |
| 203 | +`C` have nothing in common, they may still share a few empty lines and |
| 204 | +such, possibly making the assignment `1--C`, `o--o` slightly cheaper |
| 205 | +than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the |
| 206 | +fudge factor we require a much larger common part to consider patches as |
| 207 | +corresponding. |
| 208 | + |
| 209 | +The overall time needed to compute this algorithm is the time needed to |
| 210 | +compute n+m commit diffs and then n*m diffs of patches, plus the time |
| 211 | +needed to compute the least-cost assigment between n and m diffs. Git |
| 212 | +uses an implementation of the Jonker-Volgenant algorithm to solve the |
| 213 | +assignment problem, which has cubic runtime complexity. The matching |
| 214 | +found in this case will look like this: |
| 215 | + |
| 216 | +------------ |
| 217 | + 1 ----. A |
| 218 | + | / |
| 219 | + 2 ----+---' B |
| 220 | + .--+-----' |
| 221 | + o -' `----- C |
| 222 | + c>0 |
| 223 | + o ---------- o |
| 224 | + |
| 225 | + o ---------- o |
| 226 | +------------ |
| 227 | + |
| 228 | + |
| 229 | +SEE ALSO |
| 230 | +-------- |
| 231 | +linkgit:git-log[1] |
| 232 | + |
| 233 | +GIT |
| 234 | +--- |
| 235 | +Part of the linkgit:git[1] suite |
0 commit comments