]>
Commit | Line | Data |
---|---|---|
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 | [--no-dual-color] [--creation-factor=<factor>] | |
13 | [--left-only | --right-only] | |
14 | ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> ) | |
15 | ||
16 | DESCRIPTION | |
17 | ----------- | |
18 | ||
19 | This command shows the differences between two versions of a patch | |
20 | series, or more generally, two commit ranges (ignoring merge commits). | |
21 | ||
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. | |
27 | ||
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. | |
31 | ||
32 | There are three ways to specify the commit ranges: | |
33 | ||
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. | |
37 | ||
38 | - `<rev1>...<rev2>`. This is equivalent to | |
39 | `<rev2>..<rev1> <rev1>..<rev2>`. | |
40 | ||
41 | - `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1> | |
42 | <base>..<rev2>`. | |
43 | ||
44 | OPTIONS | |
45 | ------- | |
46 | --no-dual-color:: | |
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. | |
51 | + | |
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`). | |
59 | + | |
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). | |
63 | ||
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 | |
70 | needed. | |
71 | ||
72 | --left-only:: | |
73 | Suppress commits that are missing from the first specified range | |
74 | (or the "left range" when using the `<rev1>...<rev2>` format). | |
75 | ||
76 | --right-only:: | |
77 | Suppress commits that are missing from the second specified range | |
78 | (or the "right range" when using the `<rev1>...<rev2>` format). | |
79 | ||
80 | --[no-]notes[=<ref>]:: | |
81 | This flag is passed to the `git log` program | |
82 | (see linkgit:git-log[1]) that generates the patches. | |
83 | ||
84 | <range1> <range2>:: | |
85 | Compare the commits specified by the two ranges, where | |
86 | `<range1>` is considered an older version of `<range2>`. | |
87 | ||
88 | <rev1>...<rev2>:: | |
89 | Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`. | |
90 | ||
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. | |
97 | ||
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. | |
104 | ||
105 | OUTPUT STABILITY | |
106 | ---------------- | |
107 | ||
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 | |
114 | be machine-readable. | |
115 | ||
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). | |
122 | ||
123 | CONFIGURATION | |
124 | ------------- | |
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]. | |
128 | ||
129 | ||
130 | EXAMPLES | |
131 | -------- | |
132 | ||
133 | When a rebase required merge conflicts to be resolved, compare the changes | |
134 | introduced by the rebase directly afterwards using: | |
135 | ||
136 | ------------ | |
137 | $ git range-diff @{u} @{1} @ | |
138 | ------------ | |
139 | ||
140 | ||
141 | A typical output of `git range-diff` would look like this: | |
142 | ||
143 | ------------ | |
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 | |
147 | @@ -1,3 +1,3 @@ | |
148 | Author: A U Thor <author@example.com> | |
149 | ||
150 | -TODO: Describe a bug | |
151 | +Describe a bug | |
152 | @@ -324,5 +324,6 | |
153 | This is expected. | |
154 | ||
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. | |
158 | ||
159 | Contact | |
160 | 3: bedead < -: ------- TO-UNDO | |
161 | ------------ | |
162 | ||
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. | |
166 | ||
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. | |
173 | ||
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. | |
178 | ||
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 | |
183 | changed. | |
184 | ||
185 | ||
186 | Algorithm | |
187 | --------- | |
188 | ||
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. | |
191 | ||
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. | |
195 | ||
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. | |
200 | ||
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: | |
205 | ||
206 | ------------ | |
207 | 1 A | |
208 | ||
209 | 2 B | |
210 | ||
211 | C | |
212 | ------------ | |
213 | ||
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: | |
216 | ||
217 | ||
218 | ------------ | |
219 | 1 A | |
220 | / | |
221 | 2 --------' B | |
222 | ||
223 | C | |
224 | ------------ | |
225 | ||
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: | |
229 | ||
230 | ------------ | |
231 | 1 ----. A | |
232 | | / | |
233 | 2 ----+---' B | |
234 | | | |
235 | `----- C | |
236 | c>0 | |
237 | ------------ | |
238 | ||
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 | |
244 | on both sides: | |
245 | ||
246 | ------------ | |
247 | 1 ----. A | |
248 | | / | |
249 | 2 ----+---' B | |
250 | | | |
251 | o `----- C | |
252 | c>0 | |
253 | o o | |
254 | ||
255 | o o | |
256 | ------------ | |
257 | ||
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 | |
265 | corresponding. | |
266 | ||
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: | |
273 | ||
274 | ------------ | |
275 | 1 ----. A | |
276 | | / | |
277 | 2 ----+---' B | |
278 | .--+-----' | |
279 | o -' `----- C | |
280 | c>0 | |
281 | o ---------- o | |
282 | ||
283 | o ---------- o | |
284 | ------------ | |
285 | ||
286 | ||
287 | SEE ALSO | |
288 | -------- | |
289 | linkgit:git-log[1] | |
290 | ||
291 | GIT | |
292 | --- | |
293 | Part of the linkgit:git[1] suite |