2015-03-11 21:32:45 +01:00
|
|
|
diff.autoRefreshIndex::
|
2011-04-06 20:46:49 +02:00
|
|
|
When using 'git diff' to compare with work tree
|
|
|
|
files, do not consider stat-only change as changed.
|
|
|
|
Instead, silently run `git update-index --refresh` to
|
|
|
|
update the cached stat information for paths whose
|
|
|
|
contents in the work tree match the contents in the
|
|
|
|
index. This option defaults to true. Note that this
|
|
|
|
affects only 'git diff' Porcelain, and not lower level
|
|
|
|
'diff' commands such as 'git diff-files'.
|
|
|
|
|
2011-04-29 11:36:19 +02:00
|
|
|
diff.dirstat::
|
|
|
|
A comma separated list of `--dirstat` parameters specifying the
|
|
|
|
default behavior of the `--dirstat` option to linkgit:git-diff[1]`
|
|
|
|
and friends. The defaults can be overridden on the command line
|
|
|
|
(using `--dirstat=<param1,param2,...>`). The fallback defaults
|
|
|
|
(when not changed by `diff.dirstat`) are `changes,noncumulative,3`.
|
|
|
|
The following parameters are available:
|
|
|
|
+
|
|
|
|
--
|
|
|
|
`changes`;;
|
|
|
|
Compute the dirstat numbers by counting the lines that have been
|
|
|
|
removed from the source, or added to the destination. This ignores
|
|
|
|
the amount of pure code movements within a file. In other words,
|
|
|
|
rearranging lines in a file is not counted as much as other changes.
|
|
|
|
This is the default behavior when no parameter is given.
|
New --dirstat=lines mode, doing dirstat analysis based on diffstat
This patch adds an alternative implementation of show_dirstat(), called
show_dirstat_by_line(), which uses the more expensive diffstat analysis
(as opposed to show_dirstat()'s own (relatively inexpensive) analysis)
to derive the numbers from which the --dirstat output is computed.
The alternative implementation is controlled by the new "lines" parameter
to the --dirstat option (or the diff.dirstat config variable).
For binary files, the diffstat analysis counts bytes instead of lines,
so to prevent binary files from dominating the dirstat results, the
byte counts for binary files are divided by 64 before being compared to
their textual/line-based counterparts. This is a stupid and ugly - but
very cheap - heuristic.
In linux-2.6.git, running the three different --dirstat modes:
time git diff v2.6.20..v2.6.30 --dirstat=changes > /dev/null
vs.
time git diff v2.6.20..v2.6.30 --dirstat=lines > /dev/null
vs.
time git diff v2.6.20..v2.6.30 --dirstat=files > /dev/null
yields the following average runtimes on my machine:
- "changes" (default): ~6.0 s
- "lines": ~9.6 s
- "files": ~0.1 s
So, as expected, there's a considerable performance hit (~60%) by going
through the full diffstat analysis as compared to the default "changes"
analysis (obviously, "files" is much faster than both). As such, the
"lines" mode is probably only useful if you really need the --dirstat
numbers to be consistent with the numbers returned from the other
--*stat options.
The patch also includes documentation and tests for the new dirstat mode.
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29 11:36:21 +02:00
|
|
|
`lines`;;
|
|
|
|
Compute the dirstat numbers by doing the regular line-based diff
|
|
|
|
analysis, and summing the removed/added line counts. (For binary
|
|
|
|
files, count 64-byte chunks instead, since binary files have no
|
|
|
|
natural concept of lines). This is a more expensive `--dirstat`
|
|
|
|
behavior than the `changes` behavior, but it does count rearranged
|
|
|
|
lines within a file as much as other changes. The resulting output
|
|
|
|
is consistent with what you get from the other `--*stat` options.
|
2011-04-29 11:36:19 +02:00
|
|
|
`files`;;
|
|
|
|
Compute the dirstat numbers by counting the number of files changed.
|
|
|
|
Each changed file counts equally in the dirstat analysis. This is
|
|
|
|
the computationally cheapest `--dirstat` behavior, since it does
|
|
|
|
not have to look at the file contents at all.
|
|
|
|
`cumulative`;;
|
|
|
|
Count changes in a child directory for the parent directory as well.
|
|
|
|
Note that when using `cumulative`, the sum of the percentages
|
|
|
|
reported may exceed 100%. The default (non-cumulative) behavior can
|
|
|
|
be specified with the `noncumulative` parameter.
|
|
|
|
<limit>;;
|
|
|
|
An integer parameter specifies a cut-off percent (3% by default).
|
|
|
|
Directories contributing less than this percentage of the changes
|
|
|
|
are not shown in the output.
|
|
|
|
--
|
|
|
|
+
|
|
|
|
Example: The following will count changed files, while ignoring
|
|
|
|
directories with less than 10% of the total amount of changed files,
|
|
|
|
and accumulating child directory counts in the parent directories:
|
|
|
|
`files,10,cumulative`.
|
|
|
|
|
2012-03-01 13:26:46 +01:00
|
|
|
diff.statGraphWidth::
|
|
|
|
Limit the width of the graph part in --stat output. If set, applies
|
2012-06-19 19:56:09 +02:00
|
|
|
to all commands generating --stat output except format-patch.
|
2012-03-01 13:26:46 +01:00
|
|
|
|
2012-09-27 21:12:52 +02:00
|
|
|
diff.context::
|
2012-12-08 00:15:59 +01:00
|
|
|
Generate diffs with <n> lines of context instead of the default
|
|
|
|
of 3. This value is overridden by the -U option.
|
2012-09-27 21:12:52 +02:00
|
|
|
|
2011-04-06 20:46:49 +02:00
|
|
|
diff.external::
|
|
|
|
If this config variable is set, diff generation is not
|
|
|
|
performed using the internal diff machinery, but using the
|
|
|
|
given command. Can be overridden with the `GIT_EXTERNAL_DIFF'
|
|
|
|
environment variable. The command is called with parameters
|
|
|
|
as described under "git Diffs" in linkgit:git[1]. Note: if
|
|
|
|
you want to use an external diff program only on a subset of
|
|
|
|
your files, you might want to use linkgit:gitattributes[5] instead.
|
|
|
|
|
|
|
|
diff.ignoreSubmodules::
|
|
|
|
Sets the default value of --ignore-submodules. Note that this
|
|
|
|
affects only 'git diff' Porcelain, and not lower level 'diff'
|
|
|
|
commands such as 'git diff-files'. 'git checkout' also honors
|
2013-09-11 21:07:15 +02:00
|
|
|
this setting when reporting uncommitted changes. Setting it to
|
|
|
|
'all' disables the submodule summary normally shown by 'git commit'
|
2016-06-08 19:23:16 +02:00
|
|
|
and 'git status' when `status.submoduleSummary` is set unless it is
|
2014-05-21 20:52:26 +02:00
|
|
|
overridden by using the --ignore-submodules command-line option.
|
2013-09-11 21:07:15 +02:00
|
|
|
The 'git submodule' commands are not affected by this setting.
|
2011-04-06 20:46:49 +02:00
|
|
|
|
2015-03-11 21:32:45 +01:00
|
|
|
diff.mnemonicPrefix::
|
2011-04-06 20:46:49 +02:00
|
|
|
If set, 'git diff' uses a prefix pair that is different from the
|
|
|
|
standard "a/" and "b/" depending on what is being compared. When
|
|
|
|
this configuration is in effect, reverse diff output also swaps
|
|
|
|
the order of the prefixes:
|
|
|
|
`git diff`;;
|
|
|
|
compares the (i)ndex and the (w)ork tree;
|
|
|
|
`git diff HEAD`;;
|
|
|
|
compares a (c)ommit and the (w)ork tree;
|
|
|
|
`git diff --cached`;;
|
|
|
|
compares a (c)ommit and the (i)ndex;
|
|
|
|
`git diff HEAD:file1 file2`;;
|
|
|
|
compares an (o)bject and a (w)ork tree entity;
|
|
|
|
`git diff --no-index a b`;;
|
|
|
|
compares two non-git things (1) and (2).
|
|
|
|
|
|
|
|
diff.noprefix::
|
|
|
|
If set, 'git diff' does not show any source or destination prefix.
|
|
|
|
|
2015-03-11 21:32:45 +01:00
|
|
|
diff.orderFile::
|
2013-12-19 01:08:12 +01:00
|
|
|
File indicating how to order files within a diff, using
|
|
|
|
one shell glob pattern per line.
|
|
|
|
Can be overridden by the '-O' option to linkgit:git-diff[1].
|
|
|
|
|
2011-04-06 20:46:49 +02:00
|
|
|
diff.renameLimit::
|
|
|
|
The number of files to consider when performing the copy/rename
|
2016-06-28 13:40:10 +02:00
|
|
|
detection; equivalent to the 'git diff' option `-l`.
|
2011-04-06 20:46:49 +02:00
|
|
|
|
|
|
|
diff.renames::
|
2016-02-25 09:59:17 +01:00
|
|
|
Whether and how Git detects renames. If set to "false",
|
|
|
|
rename detection is disabled. If set to "true", basic rename
|
|
|
|
detection is enabled. If set to "copies" or "copy", Git will
|
2016-02-25 09:59:21 +01:00
|
|
|
detect copies, as well. Defaults to true. Note that this
|
2016-02-25 09:59:17 +01:00
|
|
|
affects only 'git diff' Porcelain like linkgit:git-diff[1] and
|
|
|
|
linkgit:git-log[1], and not lower level commands such as
|
|
|
|
linkgit:git-diff-files[1].
|
2011-04-06 20:46:49 +02:00
|
|
|
|
|
|
|
diff.suppressBlankEmpty::
|
|
|
|
A boolean to inhibit the standard behavior of printing a space
|
|
|
|
before each empty output line. Defaults to false.
|
|
|
|
|
2012-11-13 16:42:45 +01:00
|
|
|
diff.submodule::
|
|
|
|
Specify the format in which differences in submodules are
|
2016-09-01 01:27:25 +02:00
|
|
|
shown. The "short" format just shows the names of the commits
|
|
|
|
at the beginning and end of the range. The "log" format lists
|
|
|
|
the commits in the range like linkgit:git-submodule[1] `summary`
|
|
|
|
does. The "diff" format shows an inline diff of the changed
|
|
|
|
contents of the submodule. Defaults to "short".
|
2012-11-13 16:42:45 +01:00
|
|
|
|
2012-11-13 16:42:44 +01:00
|
|
|
diff.wordRegex::
|
|
|
|
A POSIX Extended Regular Expression used to determine what is a "word"
|
|
|
|
when performing word-by-word difference calculations. Character
|
|
|
|
sequences that match the regular expression are "words", all other
|
|
|
|
characters are *ignorable* whitespace.
|
|
|
|
|
2011-04-06 20:46:49 +02:00
|
|
|
diff.<driver>.command::
|
|
|
|
The custom diff driver command. See linkgit:gitattributes[5]
|
|
|
|
for details.
|
|
|
|
|
|
|
|
diff.<driver>.xfuncname::
|
|
|
|
The regular expression that the diff driver should use to
|
|
|
|
recognize the hunk header. A built-in pattern may also be used.
|
|
|
|
See linkgit:gitattributes[5] for details.
|
|
|
|
|
|
|
|
diff.<driver>.binary::
|
|
|
|
Set this option to true to make the diff driver treat files as
|
|
|
|
binary. See linkgit:gitattributes[5] for details.
|
|
|
|
|
|
|
|
diff.<driver>.textconv::
|
|
|
|
The command that the diff driver should call to generate the
|
|
|
|
text-converted version of a file. The result of the
|
|
|
|
conversion is used to generate a human-readable diff. See
|
|
|
|
linkgit:gitattributes[5] for details.
|
|
|
|
|
2015-03-11 21:32:45 +01:00
|
|
|
diff.<driver>.wordRegex::
|
2011-04-06 20:46:49 +02:00
|
|
|
The regular expression that the diff driver should use to
|
|
|
|
split words in a line. See linkgit:gitattributes[5] for
|
|
|
|
details.
|
|
|
|
|
|
|
|
diff.<driver>.cachetextconv::
|
|
|
|
Set this option to true to make the diff driver cache the text
|
|
|
|
conversion outputs. See linkgit:gitattributes[5] for details.
|
2011-04-06 20:46:50 +02:00
|
|
|
|
|
|
|
diff.tool::
|
2013-01-28 01:52:26 +01:00
|
|
|
Controls which diff tool is used by linkgit:git-difftool[1].
|
|
|
|
This variable overrides the value configured in `merge.tool`.
|
|
|
|
The list below shows the valid built-in values.
|
|
|
|
Any other value is treated as a custom diff tool and requires
|
|
|
|
that a corresponding difftool.<tool>.cmd variable is defined.
|
|
|
|
|
|
|
|
include::mergetools-diff.txt[]
|
2013-01-16 08:51:57 +01:00
|
|
|
|
diff: improve positioning of add/delete blocks in diffs
Some groups of added/deleted lines in diffs can be slid up or down,
because lines at the edges of the group are not unique. Picking good
shifts for such groups is not a matter of correctness but definitely has
a big effect on aesthetics. For example, consider the following two
diffs. The first is what standard Git emits:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $prompting) {
}
if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
+if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
The following diff is equivalent, but is obviously preferable from an
aesthetic point of view:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -230,6 +230,9 @@ if (!defined $initial_reply_to && $prompting) {
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
+if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
This patch teaches Git to pick better positions for such "diff sliders"
using heuristics that take the positions of nearby blank lines and the
indentation of nearby lines into account.
The existing Git code basically always shifts such "sliders" as far down
in the file as possible. The only exception is when the slider can be
aligned with a group of changed lines in the other file, in which case
Git favors depicting the change as one add+delete block rather than one
add and a slightly offset delete block. This naive algorithm often
yields ugly diffs.
Commit d634d61ed6 improved the situation somewhat by preferring to
position add/delete groups to make their last line a blank line, when
that is possible. This heuristic does more good than harm, but (1) it
can only help if there are blank lines in the right places, and (2)
always picks the last blank line, even if there are others that might be
better. The end result is that it makes perhaps 1/3 as many errors as
the default Git algorithm, but that still leaves a lot of ugly diffs.
This commit implements a new and much better heuristic for picking
optimal "slider" positions using the following approach: First observe
that each hypothetical positioning of a diff slider introduces two
splits: one between the context lines preceding the group and the first
added/deleted line, and the other between the last added/deleted line
and the first line of context following it. It tries to find the
positioning that creates the least bad splits.
Splits are evaluated based only on the presence and locations of nearby
blank lines, and the indentation of lines near the split. Basically, it
prefers to introduce splits adjacent to blank lines, between lines that
are indented less, and between lines with the same level of indentation.
In more detail:
1. It measures the following characteristics of a proposed splitting
position in a `struct split_measurement`:
* the number of blank lines above the proposed split
* whether the line directly after the split is blank
* the number of blank lines following that line
* the indentation of the nearest non-blank line above the split
* the indentation of the line directly below the split
* the indentation of the nearest non-blank line after that line
2. It combines the measured attributes using a bunch of
empirically-optimized weighting factors to derive a `struct
split_score` that measures the "badness" of splitting the text at
that position.
3. It combines the `split_score` for the top and the bottom of the
slider at each of its possible positions, and selects the position
that has the best `split_score`.
I determined the initial set of weighting factors by collecting a corpus
of Git histories from 29 open-source software projects in various
programming languages. I generated many diffs from this corpus, and
determined the best positioning "by eye" for about 6600 diff sliders. I
used about half of the repositories in the corpus (corresponding to
about 2/3 of the sliders) as a training set, and optimized the weights
against this corpus using a crude automated search of the parameter
space to get the best agreement with the manually-determined values.
Then I tested the resulting heuristic against the full corpus. The
results are summarized in the following table, in column `indent-1`:
| repository | count | Git 2.9.0 | compaction | compaction-fixed | indent-1 | indent-2 |
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| afnetworking | 109 | 89 (81.7%) | 37 (33.9%) | 37 (33.9%) | 2 (1.8%) | 2 (1.8%) |
| alamofire | 30 | 18 (60.0%) | 14 (46.7%) | 15 (50.0%) | 0 (0.0%) | 0 (0.0%) |
| angular | 184 | 127 (69.0%) | 39 (21.2%) | 23 (12.5%) | 5 (2.7%) | 5 (2.7%) |
| animate | 313 | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) |
| ant | 380 | 356 (93.7%) | 152 (40.0%) | 148 (38.9%) | 15 (3.9%) | 15 (3.9%) | *
| bugzilla | 306 | 263 (85.9%) | 109 (35.6%) | 99 (32.4%) | 14 (4.6%) | 15 (4.9%) | *
| corefx | 126 | 91 (72.2%) | 22 (17.5%) | 21 (16.7%) | 6 (4.8%) | 6 (4.8%) |
| couchdb | 78 | 44 (56.4%) | 26 (33.3%) | 28 (35.9%) | 6 (7.7%) | 6 (7.7%) | *
| cpython | 937 | 158 (16.9%) | 50 (5.3%) | 49 (5.2%) | 5 (0.5%) | 5 (0.5%) | *
| discourse | 160 | 95 (59.4%) | 42 (26.2%) | 36 (22.5%) | 18 (11.2%) | 13 (8.1%) |
| docker | 307 | 194 (63.2%) | 198 (64.5%) | 253 (82.4%) | 8 (2.6%) | 8 (2.6%) | *
| electron | 163 | 132 (81.0%) | 38 (23.3%) | 39 (23.9%) | 6 (3.7%) | 6 (3.7%) |
| git | 536 | 470 (87.7%) | 73 (13.6%) | 78 (14.6%) | 16 (3.0%) | 16 (3.0%) | *
| gitflow | 127 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| ionic | 133 | 89 (66.9%) | 29 (21.8%) | 38 (28.6%) | 1 (0.8%) | 1 (0.8%) |
| ipython | 482 | 362 (75.1%) | 167 (34.6%) | 169 (35.1%) | 11 (2.3%) | 11 (2.3%) | *
| junit | 161 | 147 (91.3%) | 67 (41.6%) | 66 (41.0%) | 1 (0.6%) | 1 (0.6%) | *
| lighttable | 15 | 5 (33.3%) | 0 (0.0%) | 2 (13.3%) | 0 (0.0%) | 0 (0.0%) |
| magit | 88 | 75 (85.2%) | 11 (12.5%) | 9 (10.2%) | 1 (1.1%) | 0 (0.0%) |
| neural-style | 28 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| nodejs | 781 | 649 (83.1%) | 118 (15.1%) | 111 (14.2%) | 4 (0.5%) | 5 (0.6%) | *
| phpmyadmin | 491 | 481 (98.0%) | 75 (15.3%) | 48 (9.8%) | 2 (0.4%) | 2 (0.4%) | *
| react-native | 168 | 130 (77.4%) | 79 (47.0%) | 81 (48.2%) | 0 (0.0%) | 0 (0.0%) |
| rust | 171 | 128 (74.9%) | 30 (17.5%) | 27 (15.8%) | 16 (9.4%) | 14 (8.2%) |
| spark | 186 | 149 (80.1%) | 52 (28.0%) | 52 (28.0%) | 2 (1.1%) | 2 (1.1%) |
| tensorflow | 115 | 66 (57.4%) | 48 (41.7%) | 48 (41.7%) | 5 (4.3%) | 5 (4.3%) |
| test-more | 19 | 15 (78.9%) | 2 (10.5%) | 2 (10.5%) | 1 (5.3%) | 1 (5.3%) | *
| test-unit | 51 | 34 (66.7%) | 14 (27.5%) | 8 (15.7%) | 2 (3.9%) | 2 (3.9%) | *
| xmonad | 23 | 22 (95.7%) | 2 (8.7%) | 2 (8.7%) | 1 (4.3%) | 1 (4.3%) | *
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| totals | 6668 | 4391 (65.9%) | 1496 (22.4%) | 1491 (22.4%) | 150 (2.2%) | 144 (2.2%) |
| totals (training set) | 4552 | 3195 (70.2%) | 1053 (23.1%) | 1061 (23.3%) | 86 (1.9%) | 88 (1.9%) |
| totals (test set) | 2116 | 1196 (56.5%) | 443 (20.9%) | 430 (20.3%) | 64 (3.0%) | 56 (2.6%) |
In this table, the numbers are the count and percentage of human-rated
sliders that the corresponding algorithm got *wrong*. The columns are
* "repository" - the name of the repository used. I used the diffs
between successive non-merge commits on the HEAD branch of the
corresponding repository.
* "count" - the number of sliders that were human-rated. I chose most,
but not all, sliders to rate from those among which the various
algorithms gave different answers.
* "Git 2.9.0" - the default algorithm used by `git diff` in Git 2.9.0.
* "compaction" - the heuristic used by `git diff --compaction-heuristic`
in Git 2.9.0.
* "compaction-fixed" - the heuristic used by `git diff
--compaction-heuristic` after the fixes from earlier in this patch
series. Note that the results are not dramatically different than
those for "compaction". Both produce non-ideal diffs only about 1/3 as
often as the default `git diff`.
* "indent-1" - the new `--indent-heuristic` algorithm, using the first
set of weighting factors, determined as described above.
* "indent-2" - the new `--indent-heuristic` algorithm, using the final
set of weighting factors, determined as described below.
* `*` - indicates that repo was part of training set used to determine
the first set of weighting factors.
The fact that the heuristic performed nearly as well on the test set as
on the training set in column "indent-1" is a good indication that the
heuristic was not over-trained. Given that fact, I ran a second round of
optimization, using the entire corpus as the training set. The resulting
set of weights gave the results in column "indent-2". These are the
weights included in this patch.
The final result gives consistently and significantly better results
across the whole corpus than either `git diff` or `git diff
--compaction-heuristic`. It makes only about 1/30 as many errors as the
former and about 1/10 as many errors as the latter. (And a good fraction
of the remaining errors are for diffs that involve weirdly-formatted
code, sometimes apparently machine-generated.)
The tools that were used to do this optimization and analysis, along
with the human-generated data values, are recorded in a separate project
[1].
This patch adds a new command-line option `--indent-heuristic`, and a
new configuration setting `diff.indentHeuristic`, that activate this
heuristic. This interface is only meant for testing purposes, and should
be finalized before including this change in any release.
[1] https://github.com/mhagger/diff-slider-tools
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-05 11:44:51 +02:00
|
|
|
diff.indentHeuristic::
|
2016-06-10 19:58:55 +02:00
|
|
|
diff.compactionHeuristic::
|
diff: improve positioning of add/delete blocks in diffs
Some groups of added/deleted lines in diffs can be slid up or down,
because lines at the edges of the group are not unique. Picking good
shifts for such groups is not a matter of correctness but definitely has
a big effect on aesthetics. For example, consider the following two
diffs. The first is what standard Git emits:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $prompting) {
}
if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
+if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
The following diff is equivalent, but is obviously preferable from an
aesthetic point of view:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -230,6 +230,9 @@ if (!defined $initial_reply_to && $prompting) {
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
+if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
This patch teaches Git to pick better positions for such "diff sliders"
using heuristics that take the positions of nearby blank lines and the
indentation of nearby lines into account.
The existing Git code basically always shifts such "sliders" as far down
in the file as possible. The only exception is when the slider can be
aligned with a group of changed lines in the other file, in which case
Git favors depicting the change as one add+delete block rather than one
add and a slightly offset delete block. This naive algorithm often
yields ugly diffs.
Commit d634d61ed6 improved the situation somewhat by preferring to
position add/delete groups to make their last line a blank line, when
that is possible. This heuristic does more good than harm, but (1) it
can only help if there are blank lines in the right places, and (2)
always picks the last blank line, even if there are others that might be
better. The end result is that it makes perhaps 1/3 as many errors as
the default Git algorithm, but that still leaves a lot of ugly diffs.
This commit implements a new and much better heuristic for picking
optimal "slider" positions using the following approach: First observe
that each hypothetical positioning of a diff slider introduces two
splits: one between the context lines preceding the group and the first
added/deleted line, and the other between the last added/deleted line
and the first line of context following it. It tries to find the
positioning that creates the least bad splits.
Splits are evaluated based only on the presence and locations of nearby
blank lines, and the indentation of lines near the split. Basically, it
prefers to introduce splits adjacent to blank lines, between lines that
are indented less, and between lines with the same level of indentation.
In more detail:
1. It measures the following characteristics of a proposed splitting
position in a `struct split_measurement`:
* the number of blank lines above the proposed split
* whether the line directly after the split is blank
* the number of blank lines following that line
* the indentation of the nearest non-blank line above the split
* the indentation of the line directly below the split
* the indentation of the nearest non-blank line after that line
2. It combines the measured attributes using a bunch of
empirically-optimized weighting factors to derive a `struct
split_score` that measures the "badness" of splitting the text at
that position.
3. It combines the `split_score` for the top and the bottom of the
slider at each of its possible positions, and selects the position
that has the best `split_score`.
I determined the initial set of weighting factors by collecting a corpus
of Git histories from 29 open-source software projects in various
programming languages. I generated many diffs from this corpus, and
determined the best positioning "by eye" for about 6600 diff sliders. I
used about half of the repositories in the corpus (corresponding to
about 2/3 of the sliders) as a training set, and optimized the weights
against this corpus using a crude automated search of the parameter
space to get the best agreement with the manually-determined values.
Then I tested the resulting heuristic against the full corpus. The
results are summarized in the following table, in column `indent-1`:
| repository | count | Git 2.9.0 | compaction | compaction-fixed | indent-1 | indent-2 |
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| afnetworking | 109 | 89 (81.7%) | 37 (33.9%) | 37 (33.9%) | 2 (1.8%) | 2 (1.8%) |
| alamofire | 30 | 18 (60.0%) | 14 (46.7%) | 15 (50.0%) | 0 (0.0%) | 0 (0.0%) |
| angular | 184 | 127 (69.0%) | 39 (21.2%) | 23 (12.5%) | 5 (2.7%) | 5 (2.7%) |
| animate | 313 | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) |
| ant | 380 | 356 (93.7%) | 152 (40.0%) | 148 (38.9%) | 15 (3.9%) | 15 (3.9%) | *
| bugzilla | 306 | 263 (85.9%) | 109 (35.6%) | 99 (32.4%) | 14 (4.6%) | 15 (4.9%) | *
| corefx | 126 | 91 (72.2%) | 22 (17.5%) | 21 (16.7%) | 6 (4.8%) | 6 (4.8%) |
| couchdb | 78 | 44 (56.4%) | 26 (33.3%) | 28 (35.9%) | 6 (7.7%) | 6 (7.7%) | *
| cpython | 937 | 158 (16.9%) | 50 (5.3%) | 49 (5.2%) | 5 (0.5%) | 5 (0.5%) | *
| discourse | 160 | 95 (59.4%) | 42 (26.2%) | 36 (22.5%) | 18 (11.2%) | 13 (8.1%) |
| docker | 307 | 194 (63.2%) | 198 (64.5%) | 253 (82.4%) | 8 (2.6%) | 8 (2.6%) | *
| electron | 163 | 132 (81.0%) | 38 (23.3%) | 39 (23.9%) | 6 (3.7%) | 6 (3.7%) |
| git | 536 | 470 (87.7%) | 73 (13.6%) | 78 (14.6%) | 16 (3.0%) | 16 (3.0%) | *
| gitflow | 127 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| ionic | 133 | 89 (66.9%) | 29 (21.8%) | 38 (28.6%) | 1 (0.8%) | 1 (0.8%) |
| ipython | 482 | 362 (75.1%) | 167 (34.6%) | 169 (35.1%) | 11 (2.3%) | 11 (2.3%) | *
| junit | 161 | 147 (91.3%) | 67 (41.6%) | 66 (41.0%) | 1 (0.6%) | 1 (0.6%) | *
| lighttable | 15 | 5 (33.3%) | 0 (0.0%) | 2 (13.3%) | 0 (0.0%) | 0 (0.0%) |
| magit | 88 | 75 (85.2%) | 11 (12.5%) | 9 (10.2%) | 1 (1.1%) | 0 (0.0%) |
| neural-style | 28 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| nodejs | 781 | 649 (83.1%) | 118 (15.1%) | 111 (14.2%) | 4 (0.5%) | 5 (0.6%) | *
| phpmyadmin | 491 | 481 (98.0%) | 75 (15.3%) | 48 (9.8%) | 2 (0.4%) | 2 (0.4%) | *
| react-native | 168 | 130 (77.4%) | 79 (47.0%) | 81 (48.2%) | 0 (0.0%) | 0 (0.0%) |
| rust | 171 | 128 (74.9%) | 30 (17.5%) | 27 (15.8%) | 16 (9.4%) | 14 (8.2%) |
| spark | 186 | 149 (80.1%) | 52 (28.0%) | 52 (28.0%) | 2 (1.1%) | 2 (1.1%) |
| tensorflow | 115 | 66 (57.4%) | 48 (41.7%) | 48 (41.7%) | 5 (4.3%) | 5 (4.3%) |
| test-more | 19 | 15 (78.9%) | 2 (10.5%) | 2 (10.5%) | 1 (5.3%) | 1 (5.3%) | *
| test-unit | 51 | 34 (66.7%) | 14 (27.5%) | 8 (15.7%) | 2 (3.9%) | 2 (3.9%) | *
| xmonad | 23 | 22 (95.7%) | 2 (8.7%) | 2 (8.7%) | 1 (4.3%) | 1 (4.3%) | *
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| totals | 6668 | 4391 (65.9%) | 1496 (22.4%) | 1491 (22.4%) | 150 (2.2%) | 144 (2.2%) |
| totals (training set) | 4552 | 3195 (70.2%) | 1053 (23.1%) | 1061 (23.3%) | 86 (1.9%) | 88 (1.9%) |
| totals (test set) | 2116 | 1196 (56.5%) | 443 (20.9%) | 430 (20.3%) | 64 (3.0%) | 56 (2.6%) |
In this table, the numbers are the count and percentage of human-rated
sliders that the corresponding algorithm got *wrong*. The columns are
* "repository" - the name of the repository used. I used the diffs
between successive non-merge commits on the HEAD branch of the
corresponding repository.
* "count" - the number of sliders that were human-rated. I chose most,
but not all, sliders to rate from those among which the various
algorithms gave different answers.
* "Git 2.9.0" - the default algorithm used by `git diff` in Git 2.9.0.
* "compaction" - the heuristic used by `git diff --compaction-heuristic`
in Git 2.9.0.
* "compaction-fixed" - the heuristic used by `git diff
--compaction-heuristic` after the fixes from earlier in this patch
series. Note that the results are not dramatically different than
those for "compaction". Both produce non-ideal diffs only about 1/3 as
often as the default `git diff`.
* "indent-1" - the new `--indent-heuristic` algorithm, using the first
set of weighting factors, determined as described above.
* "indent-2" - the new `--indent-heuristic` algorithm, using the final
set of weighting factors, determined as described below.
* `*` - indicates that repo was part of training set used to determine
the first set of weighting factors.
The fact that the heuristic performed nearly as well on the test set as
on the training set in column "indent-1" is a good indication that the
heuristic was not over-trained. Given that fact, I ran a second round of
optimization, using the entire corpus as the training set. The resulting
set of weights gave the results in column "indent-2". These are the
weights included in this patch.
The final result gives consistently and significantly better results
across the whole corpus than either `git diff` or `git diff
--compaction-heuristic`. It makes only about 1/30 as many errors as the
former and about 1/10 as many errors as the latter. (And a good fraction
of the remaining errors are for diffs that involve weirdly-formatted
code, sometimes apparently machine-generated.)
The tools that were used to do this optimization and analysis, along
with the human-generated data values, are recorded in a separate project
[1].
This patch adds a new command-line option `--indent-heuristic`, and a
new configuration setting `diff.indentHeuristic`, that activate this
heuristic. This interface is only meant for testing purposes, and should
be finalized before including this change in any release.
[1] https://github.com/mhagger/diff-slider-tools
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-05 11:44:51 +02:00
|
|
|
Set one of these options to `true` to enable one of two
|
|
|
|
experimental heuristics that shift diff hunk boundaries to
|
|
|
|
make patches easier to read.
|
2016-06-10 19:58:55 +02:00
|
|
|
|
2013-01-16 08:51:57 +01:00
|
|
|
diff.algorithm::
|
|
|
|
Choose a diff algorithm. The variants are as follows:
|
|
|
|
+
|
|
|
|
--
|
|
|
|
`default`, `myers`;;
|
|
|
|
The basic greedy diff algorithm. Currently, this is the default.
|
|
|
|
`minimal`;;
|
|
|
|
Spend extra time to make sure the smallest possible diff is
|
|
|
|
produced.
|
|
|
|
`patience`;;
|
|
|
|
Use "patience diff" algorithm when generating patches.
|
|
|
|
`histogram`;;
|
|
|
|
This algorithm extends the patience algorithm to "support
|
|
|
|
low-occurrence common elements".
|
|
|
|
--
|
|
|
|
+
|