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
|
2019-03-06 07:30:14 +01:00
|
|
|
default behavior of the `--dirstat` option to linkgit:git-diff[1]
|
2011-04-29 11:36:19 +02:00
|
|
|
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
|
|
|
|
2017-01-12 13:21:11 +01:00
|
|
|
diff.interHunkContext::
|
|
|
|
Show the context between diff hunks, up to the specified number
|
|
|
|
of lines, thereby fusing the hunks that are close to each other.
|
|
|
|
This value serves as the default for the `--inter-hunk-context`
|
|
|
|
command line option.
|
|
|
|
|
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
|
2019-03-06 07:30:18 +01:00
|
|
|
your files, you might want to use linkgit:gitattributes[5] instead.
|
2011-04-06 20:46:49 +02:00
|
|
|
|
|
|
|
diff.ignoreSubmodules::
|
|
|
|
Sets the default value of --ignore-submodules. Note that this
|
|
|
|
affects only 'git diff' Porcelain, and not lower level 'diff'
|
2019-03-29 11:39:05 +01:00
|
|
|
commands such as 'git diff-files'. 'git checkout'
|
|
|
|
and 'git switch' also honor
|
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.
|
2020-11-10 09:39:00 +01:00
|
|
|
By default this is set to untracked so that any untracked
|
|
|
|
submodules are ignored.
|
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.
|
|
|
|
|
2020-05-22 12:46:18 +02:00
|
|
|
diff.relative::
|
|
|
|
If set to 'true', 'git diff' does not show changes outside of the directory
|
|
|
|
and show pathnames relative to the current directory.
|
|
|
|
|
2015-03-11 21:32:45 +01:00
|
|
|
diff.orderFile::
|
2017-01-15 23:16:31 +01:00
|
|
|
File indicating how to order files within a diff.
|
|
|
|
See the '-O' option to linkgit:git-diff[1] for details.
|
2017-01-15 23:16:30 +01:00
|
|
|
If `diff.orderFile` is a relative pathname, it is treated as
|
|
|
|
relative to the top of the working tree.
|
2013-12-19 01:08:12 +01:00
|
|
|
|
2011-04-06 20:46:49 +02:00
|
|
|
diff.renameLimit::
|
2021-07-15 02:45:22 +02:00
|
|
|
The number of files to consider in the exhaustive portion of
|
|
|
|
copy/rename detection; equivalent to the 'git diff' option
|
rename: bump limit defaults yet again
These were last bumped in commit 92c57e5c1d29 (bump rename limit
defaults (again), 2011-02-19), and were bumped both because processors
had gotten faster, and because people were getting ugly merges that
caused problems and reporting it to the mailing list (suggesting that
folks were willing to spend more time waiting).
Since that time:
* Linus has continued recommending kernel folks to set
diff.renameLimit=0 (maps to 32767, currently)
* Folks with repositories with lots of renames were happy to set
merge.renameLimit above 32767, once the code supported that, to
get correct cherry-picks
* Processors have gotten faster
* It has been discovered that the timing methodology used last time
probably used too large example files.
The last point is probably worth explaining a bit more:
* The "average" file size used appears to have been average blob size
in the linux kernel history at the time (probably v2.6.25 or
something close to it).
* Since bigger files are modified more frequently, such a computation
weights towards larger files.
* Larger files may be more likely to be modified over time, but are
not more likely to be renamed -- the mean and median blob size
within a tree are a bit higher than the mean and median of blob
sizes in the history leading up to that version for the linux
kernel.
* The mean blob size in v2.6.25 was half the average blob size in
history leading to that point
* The median blob size in v2.6.25 was about 40% of the mean blob size
in v2.6.25.
* Since the mean blob size is more than double the median blob size,
any file as big as the mean will not be compared to any files of
median size or less (because they'd be more than 50% dissimilar).
* Since it is the number of files compared that provides the O(n^2)
behavior, median-sized files should matter more than mean-sized
ones.
The combined effect of the above is that the file size used in past
calculations was likely about 5x too large. Combine that with a CPU
performance improvement of ~30%, and we can increase the limits by
a factor of sqrt(5/(1-.3)) = 2.67, while keeping the original stated
time limits.
Keeping the same approximate time limit probably makes sense for
diff.renameLimit (there is no progress feedback in e.g. git log -p),
but the experience above suggests merge.renameLimit could be extended
significantly. In fact, it probably would make sense to have an
unlimited default setting for merge.renameLimit, but that would
likely need to be coupled with changes to how progress is displayed.
(See https://lore.kernel.org/git/YOx+Ok%2FEYvLqRMzJ@coredump.intra.peff.net/
for details in that area.) For now, let's just bump the approximate
time limit from 10s to 1m.
(Note: We do not want to use actual time limits, because getting results
that depend on how loaded your system is that day feels bad, and because
we don't discover that we won't get all the renames until after we've
put in a lot of work rather than just upfront telling the user there are
too many files involved.)
Using the original time limit of 2s for diff.renameLimit, and bumping
merge.renameLimit from 10s to 60s, I found the following timings using
the simple script at the end of this commit message (on an AWS c5.xlarge
which reports as "Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz"):
N Timing
1300 1.995s
7100 59.973s
So let's round down to nice even numbers and bump the limits from
400->1000, and from 1000->7000.
Here is the measure_rename_perf script (adapted from
https://lore.kernel.org/git/20080211113516.GB6344@coredump.intra.peff.net/
in particular to avoid triggering the linear handling from
basename-guided rename detection):
#!/bin/bash
n=$1; shift
rm -rf repo
mkdir repo && cd repo
git init -q -b main
mkdata() {
mkdir $1
for i in `seq 1 $2`; do
(sed "s/^/$i /" <../sample
echo tag: $1
) >$1/$i
done
}
mkdata initial $n
git add .
git commit -q -m initial
mkdata new $n
git add .
cd new
for i in *; do git mv $i $i.renamed; done
cd ..
git rm -q -rf initial
git commit -q -m new
time git diff-tree -M -l0 --summary HEAD^ HEAD
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-15 02:45:24 +02:00
|
|
|
`-l`. If not set, the default value is currently 1000. This
|
2021-07-15 02:45:22 +02:00
|
|
|
setting has no effect if rename detection is turned off.
|
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.
|
|
|
|
|
2018-10-24 18:25:43 +02:00
|
|
|
diff.guitool::
|
|
|
|
Controls which diff tool is used by linkgit:git-difftool[1] when
|
|
|
|
the -g/--gui flag is specified. This variable overrides the value
|
|
|
|
configured in `merge.guitool`. 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.<guitool>.cmd variable
|
|
|
|
is defined.
|
|
|
|
|
2018-10-27 08:22:51 +02:00
|
|
|
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::
|
2019-08-15 11:12:45 +02:00
|
|
|
Set this option to `false` to disable the default heuristics
|
2016-12-23 21:32:22 +01:00
|
|
|
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".
|
|
|
|
--
|
|
|
|
+
|
2016-10-05 00:26:27 +02:00
|
|
|
|
|
|
|
diff.wsErrorHighlight::
|
2017-07-25 22:53:15 +02:00
|
|
|
Highlight whitespace errors in the `context`, `old` or `new`
|
|
|
|
lines of the diff. Multiple values are separated by comma,
|
|
|
|
`none` resets previous values, `default` reset the list to
|
|
|
|
`new` and `all` is a shorthand for `old,new,context`. The
|
|
|
|
whitespace errors are colored with `color.diff.whitespace`.
|
|
|
|
The command line option `--ws-error-highlight=<kind>`
|
|
|
|
overrides this setting.
|
2018-08-19 12:52:10 +02:00
|
|
|
|
|
|
|
diff.colorMoved::
|
|
|
|
If set to either a valid `<mode>` or a true value, moved lines
|
|
|
|
in a diff are colored differently, for details of valid modes
|
|
|
|
see '--color-moved' in linkgit:git-diff[1]. If simply set to
|
|
|
|
true the default color mode will be used. When set to false,
|
|
|
|
moved lines are not colored.
|
|
|
|
|
|
|
|
diff.colorMovedWS::
|
|
|
|
When moved lines are colored using e.g. the `diff.colorMoved` setting,
|
|
|
|
this option controls the `<mode>` how spaces are treated
|
|
|
|
for details of valid modes see '--color-moved-ws' in linkgit:git-diff[1].
|