| 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 | [synopsis] |
| 11 | git range-diff [--color=[<when>]] [--no-color] [<diff-options>] |
| 12 | [--no-dual-color] [--creation-factor=<factor>] |
| 13 | [--left-only | --right-only] [--diff-merges=<format>] |
| 14 | [--remerge-diff] [--no-notes | --notes[=<ref>]] |
| 15 | ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> ) |
| 16 | [[--] <path>...] |
| 17 | |
| 18 | DESCRIPTION |
| 19 | ----------- |
| 20 | |
| 21 | This command shows the differences between two versions of a patch |
| 22 | series, or more generally, two commit ranges (ignoring merge commits). |
| 23 | |
| 24 | In the presence of _<path>_ arguments, these commit ranges are limited |
| 25 | accordingly. |
| 26 | |
| 27 | To that end, it first finds pairs of commits from both commit ranges |
| 28 | that correspond with each other. Two commits are said to correspond when |
| 29 | the diff between their patches (i.e. the author information, the commit |
| 30 | message and the commit diff) is reasonably small compared to the |
| 31 | patches' size. See 'Algorithm' below for details. |
| 32 | |
| 33 | Finally, the list of matching commits is shown in the order of the |
| 34 | second commit range, with unmatched commits being inserted just after |
| 35 | all of their ancestors have been shown. |
| 36 | |
| 37 | There are three ways to specify the commit ranges: |
| 38 | |
| 39 | - `<range1> <range2>`: Either commit range can be of the form |
| 40 | `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See 'SPECIFYING RANGES' |
| 41 | in linkgit:gitrevisions[7] for more details. |
| 42 | |
| 43 | - `<rev1>...<rev2>`. This is equivalent to |
| 44 | `<rev2>..<rev1> <rev1>..<rev2>`. |
| 45 | |
| 46 | - `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1> |
| 47 | <base>..<rev2>`. |
| 48 | |
| 49 | OPTIONS |
| 50 | ------- |
| 51 | `--no-dual-color`:: |
| 52 | When the commit diffs differ, `git range-diff` recreates the |
| 53 | original diffs' coloring, and adds outer -/+ diff markers with |
| 54 | the *background* being red/green to make it easier to see e.g. |
| 55 | when there was a change in what exact lines were added. |
| 56 | + |
| 57 | Additionally, the commit diff lines that are only present in the first commit |
| 58 | range are shown "dimmed" (this can be overridden using the `color.diff.<slot>` |
| 59 | config setting where _<slot>_ is one of `contextDimmed`, `oldDimmed` and |
| 60 | `newDimmed`), and the commit diff lines that are only present in the second |
| 61 | commit range are shown in bold (which can be overridden using the config |
| 62 | settings `color.diff.<slot>` with _<slot>_ being one of `contextBold`, |
| 63 | `oldBold` or `newBold`). |
| 64 | + |
| 65 | This is known to `range-diff` as "dual coloring". Use `--no-dual-color` |
| 66 | to revert to color all lines according to the outer diff markers |
| 67 | (and completely ignore the inner diff when it comes to color). |
| 68 | |
| 69 | `--creation-factor=<percent>`:: |
| 70 | Set the creation/deletion cost fudge factor to _<percent>_. |
| 71 | Defaults to 60. Try a larger value if `git range-diff` erroneously |
| 72 | considers a large change a total rewrite (deletion of one commit |
| 73 | and addition of another), and a smaller one in the reverse case. |
| 74 | See the 'Algorithm' section below for an explanation of why this is |
| 75 | needed. |
| 76 | |
| 77 | `--left-only`:: |
| 78 | Suppress commits that are missing from the first specified range |
| 79 | (or the "left range" when using the `<rev1>...<rev2>` form). |
| 80 | |
| 81 | `--right-only`:: |
| 82 | Suppress commits that are missing from the second specified range |
| 83 | (or the "right range" when using the `<rev1>...<rev2>` form). |
| 84 | |
| 85 | `--diff-merges=<format>`:: |
| 86 | Instead of ignoring merge commits, generate diffs for them using the |
| 87 | corresponding `--diff-merges=<format>` option of linkgit:git-log[1], |
| 88 | and include them in the comparison. |
| 89 | + |
| 90 | Note: In the common case, the `remerge` mode will be the most natural one |
| 91 | to use, as it shows only the diff on top of what Git's merge machinery would |
| 92 | have produced. In other words, if a merge commit is the result of a |
| 93 | non-conflicting `git merge`, the `remerge` mode will represent it with an empty |
| 94 | diff. |
| 95 | |
| 96 | `--remerge-diff`:: |
| 97 | Convenience option, equivalent to `--diff-merges=remerge`. |
| 98 | |
| 99 | `--notes[=<ref>]`:: |
| 100 | `--no-notes`:: |
| 101 | This flag is passed to the `git log` program |
| 102 | (see linkgit:git-log[1]) that generates the patches. |
| 103 | |
| 104 | `<range1> <range2>`:: |
| 105 | Compare the commits specified by the two ranges, where |
| 106 | _<range1>_ is considered an older version of _<range2>_. |
| 107 | |
| 108 | `<rev1>...<rev2>`:: |
| 109 | Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`. |
| 110 | |
| 111 | `<base> <rev1> <rev2>`:: |
| 112 | Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`. |
| 113 | Note that _<base>_ does not need to be the exact branch point |
| 114 | of the branches. Example: after rebasing a branch `my-topic`, |
| 115 | `git range-diff my-topic@{u} my-topic@{1} my-topic` would |
| 116 | show the differences introduced by the rebase. |
| 117 | |
| 118 | `git range-diff` also accepts the regular diff options (see |
| 119 | linkgit:git-diff[1]), most notably the `--color[=<when>]` and |
| 120 | `--no-color` options. These options are used when generating the "diff |
| 121 | between patches", i.e. to compare the author, commit message and diff of |
| 122 | corresponding old/new commits. There is currently no means to tweak most of the |
| 123 | diff options passed to `git log` when generating those patches. |
| 124 | |
| 125 | OUTPUT STABILITY |
| 126 | ---------------- |
| 127 | |
| 128 | The output of the `range-diff` command is subject to change. It is |
| 129 | intended to be human-readable porcelain output, not something that can |
| 130 | be used across versions of Git to get a textually stable `range-diff` |
| 131 | (as opposed to something like the `--stable` option to |
| 132 | linkgit:git-patch-id[1]). There's also no equivalent of |
| 133 | linkgit:git-apply[1] for `range-diff`, the output is not intended to |
| 134 | be machine-readable. |
| 135 | |
| 136 | This is particularly true when passing in diff options. Currently some |
| 137 | options like `--stat` can, as an emergent effect, produce output |
| 138 | that's quite useless in the context of `range-diff`. Future versions |
| 139 | of `range-diff` may learn to interpret such options in a manner |
| 140 | specific to `range-diff` (e.g. for `--stat` producing human-readable |
| 141 | output which summarizes how the diffstat changed). |
| 142 | |
| 143 | CONFIGURATION |
| 144 | ------------- |
| 145 | This command uses the `diff.color.*` and `pager.range-diff` settings |
| 146 | (the latter is on by default). |
| 147 | See linkgit:git-config[1]. |
| 148 | |
| 149 | |
| 150 | EXAMPLES |
| 151 | -------- |
| 152 | |
| 153 | When a rebase required merge conflicts to be resolved, compare the changes |
| 154 | introduced by the rebase directly afterwards using: |
| 155 | |
| 156 | ------------ |
| 157 | $ git range-diff @{u} @{1} @ |
| 158 | ------------ |
| 159 | |
| 160 | |
| 161 | A typical output of `git range-diff` would look like this: |
| 162 | |
| 163 | ------------ |
| 164 | -: ------- > 1: 0ddba11 Prepare for the inevitable! |
| 165 | 1: c0debee = 2: cab005e Add a helpful message at the start |
| 166 | 2: f00dbal ! 3: decafe1 Describe a bug |
| 167 | @@ -1,3 +1,3 @@ |
| 168 | Author: A U Thor <author@example.com> |
| 169 | |
| 170 | -TODO: Describe a bug |
| 171 | +Describe a bug |
| 172 | @@ -324,5 +324,6 |
| 173 | This is expected. |
| 174 | |
| 175 | -+What is unexpected is that it will also crash. |
| 176 | ++Unexpectedly, it also crashes. This is a bug, and the jury is |
| 177 | ++still out there how to fix it best. See ticket #314 for details. |
| 178 | |
| 179 | Contact |
| 180 | 3: bedead < -: ------- TO-UNDO |
| 181 | ------------ |
| 182 | |
| 183 | In this example, there are 3 old and 3 new commits, where the developer |
| 184 | removed the 3rd, added a new one before the first two, and modified the |
| 185 | commit message of the 2nd commit as well as its diff. |
| 186 | |
| 187 | When the output goes to a terminal, it is color-coded by default, just |
| 188 | like regular `git diff`'s output. In addition, the first line (adding a |
| 189 | commit) is green, the last line (deleting a commit) is red, the second |
| 190 | line (with a perfect match) is yellow like the commit header of `git |
| 191 | show`'s output, and the third line colors the old commit red, the new |
| 192 | one green and the rest like `git show`'s commit header. |
| 193 | |
| 194 | A naive color-coded diff of diffs is actually a bit hard to read, |
| 195 | though, as it colors the entire lines red or green. The line that added |
| 196 | "What is unexpected" in the old commit, for example, is completely red, |
| 197 | even if the intent of the old commit was to add something. |
| 198 | |
| 199 | To help with that, `range` uses the `--dual-color` mode by default. In |
| 200 | this mode, the diff of diffs will retain the original diff colors, and |
| 201 | prefix the lines with -/+ markers that have their *background* red or |
| 202 | green, to make it more obvious that they describe how the diff itself |
| 203 | changed. |
| 204 | |
| 205 | |
| 206 | Algorithm |
| 207 | --------- |
| 208 | |
| 209 | The general idea is this: we generate a cost matrix between the commits |
| 210 | in both commit ranges, then solve the least-cost assignment. |
| 211 | |
| 212 | The cost matrix is populated thusly: for each pair of commits, both |
| 213 | diffs are generated and the "diff of diffs" is generated, with 3 context |
| 214 | lines, then the number of lines in that diff is used as cost. |
| 215 | |
| 216 | To avoid false positives (e.g. when a patch has been removed, and an |
| 217 | unrelated patch has been added between two iterations of the same patch |
| 218 | series), the cost matrix is extended to allow for that, by adding |
| 219 | fixed-cost entries for wholesale deletes/adds. |
| 220 | |
| 221 | Example: Let commits `1--2` be the first iteration of a patch series and |
| 222 | `A--C` the second iteration. Let's assume that `A` is a cherry-pick of |
| 223 | `2,` and `C` is a cherry-pick of `1` but with a small modification (say, |
| 224 | a fixed typo). Visualize the commits as a bipartite graph: |
| 225 | |
| 226 | ------------ |
| 227 | 1 A |
| 228 | |
| 229 | 2 B |
| 230 | |
| 231 | C |
| 232 | ------------ |
| 233 | |
| 234 | We are looking for a "best" explanation of the new series in terms of |
| 235 | the old one. We can represent an "explanation" as an edge in the graph: |
| 236 | |
| 237 | |
| 238 | ------------ |
| 239 | 1 A |
| 240 | / |
| 241 | 2 --------' B |
| 242 | |
| 243 | C |
| 244 | ------------ |
| 245 | |
| 246 | This explanation comes for "free" because there was no change. Similarly |
| 247 | `C` could be explained using `1`, but that comes at some cost c>0 |
| 248 | because of the modification: |
| 249 | |
| 250 | ------------ |
| 251 | 1 ----. A |
| 252 | | / |
| 253 | 2 ----+---' B |
| 254 | | |
| 255 | `----- C |
| 256 | c>0 |
| 257 | ------------ |
| 258 | |
| 259 | In mathematical terms, what we are looking for is some sort of a minimum |
| 260 | cost bipartite matching; `1` is matched to `C` at some cost, etc. The |
| 261 | underlying graph is in fact a complete bipartite graph; the cost we |
| 262 | associate with every edge is the size of the diff between the two |
| 263 | commits' patches. To explain also new commits, we introduce dummy nodes |
| 264 | on both sides: |
| 265 | |
| 266 | ------------ |
| 267 | 1 ----. A |
| 268 | | / |
| 269 | 2 ----+---' B |
| 270 | | |
| 271 | o `----- C |
| 272 | c>0 |
| 273 | o o |
| 274 | |
| 275 | o o |
| 276 | ------------ |
| 277 | |
| 278 | The cost of an edge `o--C` is the size of `C`'s diff, modified by a |
| 279 | fudge factor that should be smaller than 100%. The cost of an edge |
| 280 | `o--o` is free. The fudge factor is necessary because even if `1` and |
| 281 | `C` have nothing in common, they may still share a few empty lines and |
| 282 | such, possibly making the assignment `1--C`, `o--o` slightly cheaper |
| 283 | than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the |
| 284 | fudge factor we require a much larger common part to consider patches as |
| 285 | corresponding. |
| 286 | |
| 287 | The overall time needed to compute this algorithm is the time needed to |
| 288 | compute n+m commit diffs and then n*m diffs of patches, plus the time |
| 289 | needed to compute the least-cost assignment between n and m diffs. Git |
| 290 | uses an implementation of the Jonker-Volgenant algorithm to solve the |
| 291 | assignment problem, which has cubic runtime complexity. The matching |
| 292 | found in this case will look like this: |
| 293 | |
| 294 | ------------ |
| 295 | 1 ----. A |
| 296 | | / |
| 297 | 2 ----+---' B |
| 298 | .--+-----' |
| 299 | o -' `----- C |
| 300 | c>0 |
| 301 | o ---------- o |
| 302 | |
| 303 | o ---------- o |
| 304 | ------------ |
| 305 | |
| 306 | |
| 307 | SEE ALSO |
| 308 | -------- |
| 309 | linkgit:git-log[1] |
| 310 | |
| 311 | GIT |
| 312 | --- |
| 313 | Part of the linkgit:git[1] suite |