2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2015-08-13 01:12:01 +08:00
|
|
|
#include "tempfile.h"
|
2006-04-22 14:57:45 +08:00
|
|
|
#include "quote.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "diffcore.h"
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
#include "delta.h"
|
2006-04-22 14:57:45 +08:00
|
|
|
#include "xdiff-interface.h"
|
2006-09-08 16:03:18 +08:00
|
|
|
#include "color.h"
|
2007-04-13 14:05:29 +08:00
|
|
|
#include "attr.h"
|
2007-10-20 03:47:56 +08:00
|
|
|
#include "run-command.h"
|
2008-01-02 17:50:11 +08:00
|
|
|
#include "utf8.h"
|
2018-05-16 07:42:15 +08:00
|
|
|
#include "object-store.h"
|
2008-10-06 05:43:21 +08:00
|
|
|
#include "userdiff.h"
|
2015-08-18 08:21:59 +08:00
|
|
|
#include "submodule-config.h"
|
2009-10-19 20:38:32 +08:00
|
|
|
#include "submodule.h"
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
#include "hashmap.h"
|
2021-12-09 18:30:09 +08:00
|
|
|
#include "mem-pool.h"
|
2010-03-25 10:21:32 +08:00
|
|
|
#include "ll-merge.h"
|
2012-10-29 00:50:54 +08:00
|
|
|
#include "string-list.h"
|
2020-07-29 04:23:39 +08:00
|
|
|
#include "strvec.h"
|
2016-09-01 07:27:20 +08:00
|
|
|
#include "graph.h"
|
2017-08-19 06:20:36 +08:00
|
|
|
#include "packfile.h"
|
2019-01-27 08:35:31 +08:00
|
|
|
#include "parse-options.h"
|
2018-05-26 21:55:24 +08:00
|
|
|
#include "help.h"
|
2019-06-25 21:40:31 +08:00
|
|
|
#include "promisor-remote.h"
|
2021-09-08 19:23:56 +08:00
|
|
|
#include "dir.h"
|
2022-02-02 10:37:34 +08:00
|
|
|
#include "strmap.h"
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-12-14 19:15:57 +08:00
|
|
|
#ifdef NO_FAST_WORKING_DIRECTORY
|
|
|
|
#define FAST_WORKING_DIRECTORY 0
|
|
|
|
#else
|
|
|
|
#define FAST_WORKING_DIRECTORY 1
|
|
|
|
#endif
|
|
|
|
|
2006-08-16 01:23:48 +08:00
|
|
|
static int diff_detect_rename_default;
|
2017-05-09 00:03:38 +08:00
|
|
|
static int diff_indent_heuristic = 1;
|
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 08:45:24 +08:00
|
|
|
static int diff_rename_limit_default = 1000;
|
2008-08-15 19:39:26 +08:00
|
|
|
static int diff_suppress_blank_empty;
|
2012-09-16 04:59:59 +08:00
|
|
|
static int diff_use_color_default = -1;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
static int diff_color_moved_default;
|
2018-07-19 03:31:56 +08:00
|
|
|
static int diff_color_moved_ws_default;
|
2012-09-28 03:12:52 +08:00
|
|
|
static int diff_context_default = 3;
|
2017-01-12 20:21:11 +08:00
|
|
|
static int diff_interhunk_context_default;
|
2009-01-21 11:46:57 +08:00
|
|
|
static const char *diff_word_regex_cfg;
|
2007-12-17 21:42:20 +08:00
|
|
|
static const char *external_diff_cmd_cfg;
|
2013-12-19 08:08:12 +08:00
|
|
|
static const char *diff_order_file_cfg;
|
2007-09-01 04:13:42 +08:00
|
|
|
int diff_auto_refresh_index = 1;
|
2008-08-19 11:08:09 +08:00
|
|
|
static int diff_mnemonic_prefix;
|
2010-05-03 10:03:41 +08:00
|
|
|
static int diff_no_prefix;
|
2020-05-22 18:46:18 +08:00
|
|
|
static int diff_relative;
|
2012-03-01 20:26:46 +08:00
|
|
|
static int diff_stat_graph_width;
|
2011-04-29 17:36:20 +08:00
|
|
|
static int diff_dirstat_permille_default = 30;
|
2010-08-05 16:49:55 +08:00
|
|
|
static struct diff_options default_diff_options;
|
2013-01-16 15:51:57 +08:00
|
|
|
static long diff_algorithm;
|
2016-10-05 06:26:27 +08:00
|
|
|
static unsigned ws_error_highlight_default = WSEH_NEW;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-09-08 16:03:18 +08:00
|
|
|
static char diff_colors[][COLOR_MAXLEN] = {
|
2009-02-14 05:53:40 +08:00
|
|
|
GIT_COLOR_RESET,
|
2015-05-28 04:48:46 +08:00
|
|
|
GIT_COLOR_NORMAL, /* CONTEXT */
|
2009-02-14 05:53:40 +08:00
|
|
|
GIT_COLOR_BOLD, /* METAINFO */
|
|
|
|
GIT_COLOR_CYAN, /* FRAGINFO */
|
|
|
|
GIT_COLOR_RED, /* OLD */
|
|
|
|
GIT_COLOR_GREEN, /* NEW */
|
|
|
|
GIT_COLOR_YELLOW, /* COMMIT */
|
|
|
|
GIT_COLOR_BG_RED, /* WHITESPACE */
|
2009-11-27 14:55:18 +08:00
|
|
|
GIT_COLOR_NORMAL, /* FUNCINFO */
|
2017-07-01 04:53:09 +08:00
|
|
|
GIT_COLOR_BOLD_MAGENTA, /* OLD_MOVED */
|
|
|
|
GIT_COLOR_BOLD_BLUE, /* OLD_MOVED ALTERNATIVE */
|
|
|
|
GIT_COLOR_FAINT, /* OLD_MOVED_DIM */
|
|
|
|
GIT_COLOR_FAINT_ITALIC, /* OLD_MOVED_ALTERNATIVE_DIM */
|
|
|
|
GIT_COLOR_BOLD_CYAN, /* NEW_MOVED */
|
|
|
|
GIT_COLOR_BOLD_YELLOW, /* NEW_MOVED ALTERNATIVE */
|
|
|
|
GIT_COLOR_FAINT, /* NEW_MOVED_DIM */
|
|
|
|
GIT_COLOR_FAINT_ITALIC, /* NEW_MOVED_ALTERNATIVE_DIM */
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
GIT_COLOR_FAINT, /* CONTEXT_DIM */
|
|
|
|
GIT_COLOR_FAINT_RED, /* OLD_DIM */
|
|
|
|
GIT_COLOR_FAINT_GREEN, /* NEW_DIM */
|
|
|
|
GIT_COLOR_BOLD, /* CONTEXT_BOLD */
|
|
|
|
GIT_COLOR_BOLD_RED, /* OLD_BOLD */
|
|
|
|
GIT_COLOR_BOLD_GREEN, /* NEW_BOLD */
|
2006-06-14 00:45:44 +08:00
|
|
|
};
|
|
|
|
|
2018-05-26 21:55:21 +08:00
|
|
|
static const char *color_diff_slots[] = {
|
|
|
|
[DIFF_CONTEXT] = "context",
|
|
|
|
[DIFF_METAINFO] = "meta",
|
|
|
|
[DIFF_FRAGINFO] = "frag",
|
|
|
|
[DIFF_FILE_OLD] = "old",
|
|
|
|
[DIFF_FILE_NEW] = "new",
|
|
|
|
[DIFF_COMMIT] = "commit",
|
|
|
|
[DIFF_WHITESPACE] = "whitespace",
|
|
|
|
[DIFF_FUNCINFO] = "func",
|
|
|
|
[DIFF_FILE_OLD_MOVED] = "oldMoved",
|
|
|
|
[DIFF_FILE_OLD_MOVED_ALT] = "oldMovedAlternative",
|
|
|
|
[DIFF_FILE_OLD_MOVED_DIM] = "oldMovedDimmed",
|
|
|
|
[DIFF_FILE_OLD_MOVED_ALT_DIM] = "oldMovedAlternativeDimmed",
|
|
|
|
[DIFF_FILE_NEW_MOVED] = "newMoved",
|
|
|
|
[DIFF_FILE_NEW_MOVED_ALT] = "newMovedAlternative",
|
|
|
|
[DIFF_FILE_NEW_MOVED_DIM] = "newMovedDimmed",
|
|
|
|
[DIFF_FILE_NEW_MOVED_ALT_DIM] = "newMovedAlternativeDimmed",
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
[DIFF_CONTEXT_DIM] = "contextDimmed",
|
|
|
|
[DIFF_FILE_OLD_DIM] = "oldDimmed",
|
|
|
|
[DIFF_FILE_NEW_DIM] = "newDimmed",
|
|
|
|
[DIFF_CONTEXT_BOLD] = "contextBold",
|
|
|
|
[DIFF_FILE_OLD_BOLD] = "oldBold",
|
|
|
|
[DIFF_FILE_NEW_BOLD] = "newBold",
|
2018-05-26 21:55:21 +08:00
|
|
|
};
|
|
|
|
|
2018-05-26 21:55:24 +08:00
|
|
|
define_list_config_array_extra(color_diff_slots, {"plain"});
|
|
|
|
|
2014-06-19 03:41:50 +08:00
|
|
|
static int parse_diff_color_slot(const char *var)
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
{
|
2018-05-26 21:55:21 +08:00
|
|
|
if (!strcasecmp(var, "plain"))
|
2015-05-28 04:48:46 +08:00
|
|
|
return DIFF_CONTEXT;
|
2018-05-26 21:55:21 +08:00
|
|
|
return LOOKUP_CONFIG(color_diff_slots, var);
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
}
|
|
|
|
|
2012-10-29 00:50:54 +08:00
|
|
|
static int parse_dirstat_params(struct diff_options *options, const char *params_string,
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
struct strbuf *errmsg)
|
2011-04-29 17:36:18 +08:00
|
|
|
{
|
2012-10-29 00:50:54 +08:00
|
|
|
char *params_copy = xstrdup(params_string);
|
|
|
|
struct string_list params = STRING_LIST_INIT_NODUP;
|
|
|
|
int ret = 0;
|
|
|
|
int i;
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
|
2012-10-29 00:50:54 +08:00
|
|
|
if (*params_copy)
|
|
|
|
string_list_split_in_place(¶ms, params_copy, ',', -1);
|
|
|
|
for (i = 0; i < params.nr; i++) {
|
|
|
|
const char *p = params.items[i].string;
|
|
|
|
if (!strcmp(p, "changes")) {
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirstat_by_line = 0;
|
|
|
|
options->flags.dirstat_by_file = 0;
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "lines")) {
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirstat_by_line = 1;
|
|
|
|
options->flags.dirstat_by_file = 0;
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "files")) {
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirstat_by_line = 0;
|
|
|
|
options->flags.dirstat_by_file = 1;
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "noncumulative")) {
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirstat_cumulative = 0;
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "cumulative")) {
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirstat_cumulative = 1;
|
2011-04-29 17:36:18 +08:00
|
|
|
} else if (isdigit(*p)) {
|
|
|
|
char *end;
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
int permille = strtoul(p, &end, 10) * 10;
|
|
|
|
if (*end == '.' && isdigit(*++end)) {
|
2011-04-29 17:36:20 +08:00
|
|
|
/* only use first digit */
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
permille += *end - '0';
|
2011-04-29 17:36:20 +08:00
|
|
|
/* .. and ignore any further digits */
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
while (isdigit(*++end))
|
2011-04-29 17:36:20 +08:00
|
|
|
; /* nothing */
|
|
|
|
}
|
2012-10-29 00:50:54 +08:00
|
|
|
if (!*end)
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
options->dirstat_permille = permille;
|
|
|
|
else {
|
2012-10-29 00:50:54 +08:00
|
|
|
strbuf_addf(errmsg, _(" Failed to parse dirstat cut-off percentage '%s'\n"),
|
|
|
|
p);
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
ret++;
|
|
|
|
}
|
|
|
|
} else {
|
2012-10-29 00:50:54 +08:00
|
|
|
strbuf_addf(errmsg, _(" Unknown dirstat parameter '%s'\n"), p);
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
ret++;
|
2011-04-29 17:36:18 +08:00
|
|
|
}
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
|
2011-04-29 17:36:18 +08:00
|
|
|
}
|
2012-10-29 00:50:54 +08:00
|
|
|
string_list_clear(¶ms, 0);
|
|
|
|
free(params_copy);
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
return ret;
|
2011-04-29 17:36:18 +08:00
|
|
|
}
|
|
|
|
|
2012-11-13 23:42:45 +08:00
|
|
|
static int parse_submodule_params(struct diff_options *options, const char *value)
|
|
|
|
{
|
|
|
|
if (!strcmp(value, "log"))
|
2016-09-01 07:27:21 +08:00
|
|
|
options->submodule_format = DIFF_SUBMODULE_LOG;
|
2012-11-13 23:42:45 +08:00
|
|
|
else if (!strcmp(value, "short"))
|
2016-09-01 07:27:21 +08:00
|
|
|
options->submodule_format = DIFF_SUBMODULE_SHORT;
|
2016-09-01 07:27:25 +08:00
|
|
|
else if (!strcmp(value, "diff"))
|
|
|
|
options->submodule_format = DIFF_SUBMODULE_INLINE_DIFF;
|
2019-02-16 19:24:41 +08:00
|
|
|
/*
|
|
|
|
* Please update $__git_diff_submodule_formats in
|
|
|
|
* git-completion.bash when you add new formats.
|
|
|
|
*/
|
2012-11-13 23:42:45 +08:00
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-05-03 00:01:14 +08:00
|
|
|
int git_config_rename(const char *var, const char *value)
|
2009-04-10 02:46:15 +08:00
|
|
|
{
|
|
|
|
if (!value)
|
|
|
|
return DIFF_DETECT_RENAME;
|
|
|
|
if (!strcasecmp(value, "copies") || !strcasecmp(value, "copy"))
|
|
|
|
return DIFF_DETECT_COPY;
|
|
|
|
return git_config_bool(var,value) ? DIFF_DETECT_RENAME : 0;
|
|
|
|
}
|
|
|
|
|
2013-01-16 15:51:58 +08:00
|
|
|
long parse_algorithm_value(const char *value)
|
2013-01-16 15:51:57 +08:00
|
|
|
{
|
|
|
|
if (!value)
|
|
|
|
return -1;
|
|
|
|
else if (!strcasecmp(value, "myers") || !strcasecmp(value, "default"))
|
|
|
|
return 0;
|
|
|
|
else if (!strcasecmp(value, "minimal"))
|
|
|
|
return XDF_NEED_MINIMAL;
|
|
|
|
else if (!strcasecmp(value, "patience"))
|
|
|
|
return XDF_PATIENCE_DIFF;
|
|
|
|
else if (!strcasecmp(value, "histogram"))
|
|
|
|
return XDF_HISTOGRAM_DIFF;
|
2019-02-16 19:24:41 +08:00
|
|
|
/*
|
|
|
|
* Please update $__git_diff_algorithms in git-completion.bash
|
|
|
|
* when you add new algorithms.
|
|
|
|
*/
|
2013-01-16 15:51:57 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-10-05 06:09:18 +08:00
|
|
|
static int parse_one_token(const char **arg, const char *token)
|
|
|
|
{
|
|
|
|
const char *rest;
|
|
|
|
if (skip_prefix(*arg, token, &rest) && (!*rest || *rest == ',')) {
|
|
|
|
*arg = rest;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_ws_error_highlight(const char *arg)
|
|
|
|
{
|
|
|
|
const char *orig_arg = arg;
|
|
|
|
unsigned val = 0;
|
|
|
|
|
|
|
|
while (*arg) {
|
|
|
|
if (parse_one_token(&arg, "none"))
|
|
|
|
val = 0;
|
|
|
|
else if (parse_one_token(&arg, "default"))
|
|
|
|
val = WSEH_NEW;
|
|
|
|
else if (parse_one_token(&arg, "all"))
|
|
|
|
val = WSEH_NEW | WSEH_OLD | WSEH_CONTEXT;
|
|
|
|
else if (parse_one_token(&arg, "new"))
|
|
|
|
val |= WSEH_NEW;
|
|
|
|
else if (parse_one_token(&arg, "old"))
|
|
|
|
val |= WSEH_OLD;
|
|
|
|
else if (parse_one_token(&arg, "context"))
|
|
|
|
val |= WSEH_CONTEXT;
|
|
|
|
else {
|
|
|
|
return -1 - (int)(arg - orig_arg);
|
|
|
|
}
|
|
|
|
if (*arg)
|
|
|
|
arg++;
|
|
|
|
}
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2006-07-08 16:05:16 +08:00
|
|
|
/*
|
|
|
|
* These are to give UI layer defaults.
|
|
|
|
* The core-level commands such as git-diff-files should
|
|
|
|
* never be affected by the setting of diff.renames
|
|
|
|
* the user happens to have in the configuration file.
|
|
|
|
*/
|
2016-02-25 16:59:21 +08:00
|
|
|
void init_diff_ui_defaults(void)
|
|
|
|
{
|
2017-12-27 18:18:35 +08:00
|
|
|
diff_detect_rename_default = DIFF_DETECT_RENAME;
|
2016-02-25 16:59:21 +08:00
|
|
|
}
|
|
|
|
|
2016-09-05 17:44:53 +08:00
|
|
|
int git_diff_heuristic_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
2016-12-24 04:32:22 +08:00
|
|
|
if (!strcmp(var, "diff.indentheuristic"))
|
2016-09-05 17:44:53 +08:00
|
|
|
diff_indent_heuristic = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
static int parse_color_moved(const char *arg)
|
|
|
|
{
|
|
|
|
switch (git_parse_maybe_bool(arg)) {
|
|
|
|
case 0:
|
|
|
|
return COLOR_MOVED_NO;
|
|
|
|
case 1:
|
|
|
|
return COLOR_MOVED_DEFAULT;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strcmp(arg, "no"))
|
|
|
|
return COLOR_MOVED_NO;
|
2017-07-01 04:53:08 +08:00
|
|
|
else if (!strcmp(arg, "plain"))
|
|
|
|
return COLOR_MOVED_PLAIN;
|
2018-07-17 07:05:39 +08:00
|
|
|
else if (!strcmp(arg, "blocks"))
|
|
|
|
return COLOR_MOVED_BLOCKS;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
else if (!strcmp(arg, "zebra"))
|
|
|
|
return COLOR_MOVED_ZEBRA;
|
|
|
|
else if (!strcmp(arg, "default"))
|
|
|
|
return COLOR_MOVED_DEFAULT;
|
2018-07-25 05:58:45 +08:00
|
|
|
else if (!strcmp(arg, "dimmed-zebra"))
|
|
|
|
return COLOR_MOVED_ZEBRA_DIM;
|
2017-07-01 04:53:09 +08:00
|
|
|
else if (!strcmp(arg, "dimmed_zebra"))
|
|
|
|
return COLOR_MOVED_ZEBRA_DIM;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
else
|
2018-08-16 06:08:22 +08:00
|
|
|
return error(_("color moved setting must be one of 'no', 'default', 'blocks', 'zebra', 'dimmed-zebra', 'plain'"));
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2018-11-14 05:33:57 +08:00
|
|
|
static unsigned parse_color_moved_ws(const char *arg)
|
2018-07-17 07:05:40 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
struct string_list l = STRING_LIST_INIT_DUP;
|
|
|
|
struct string_list_item *i;
|
|
|
|
|
|
|
|
string_list_split(&l, arg, ',', -1);
|
|
|
|
|
|
|
|
for_each_string_list_item(i, &l) {
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
strbuf_addstr(&sb, i->string);
|
|
|
|
strbuf_trim(&sb);
|
|
|
|
|
2018-11-23 19:16:52 +08:00
|
|
|
if (!strcmp(sb.buf, "no"))
|
|
|
|
ret = 0;
|
|
|
|
else if (!strcmp(sb.buf, "ignore-space-change"))
|
2018-07-17 07:05:40 +08:00
|
|
|
ret |= XDF_IGNORE_WHITESPACE_CHANGE;
|
|
|
|
else if (!strcmp(sb.buf, "ignore-space-at-eol"))
|
|
|
|
ret |= XDF_IGNORE_WHITESPACE_AT_EOL;
|
|
|
|
else if (!strcmp(sb.buf, "ignore-all-space"))
|
|
|
|
ret |= XDF_IGNORE_WHITESPACE;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
else if (!strcmp(sb.buf, "allow-indentation-change"))
|
|
|
|
ret |= COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE;
|
2018-11-14 05:33:57 +08:00
|
|
|
else {
|
|
|
|
ret |= COLOR_MOVED_WS_ERROR;
|
|
|
|
error(_("unknown color-moved-ws mode '%s', possible values are 'ignore-space-change', 'ignore-space-at-eol', 'ignore-all-space', 'allow-indentation-change'"), sb.buf);
|
|
|
|
}
|
2018-07-17 07:05:40 +08:00
|
|
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
|
|
|
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
if ((ret & COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE) &&
|
2018-11-14 05:33:57 +08:00
|
|
|
(ret & XDF_WHITESPACE_FLAGS)) {
|
2019-01-30 04:47:53 +08:00
|
|
|
error(_("color-moved-ws: allow-indentation-change cannot be combined with other whitespace modes"));
|
2018-11-14 05:33:57 +08:00
|
|
|
ret |= COLOR_MOVED_WS_ERROR;
|
|
|
|
}
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2018-07-17 07:05:40 +08:00
|
|
|
string_list_clear(&l, 0);
|
|
|
|
|
|
|
|
return ret;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2008-05-15 01:46:53 +08:00
|
|
|
int git_diff_ui_config(const char *var, const char *value, void *cb)
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
{
|
2006-12-13 17:13:28 +08:00
|
|
|
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
|
2011-08-18 13:03:48 +08:00
|
|
|
diff_use_color_default = git_config_colorbool(var, value);
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
if (!strcmp(var, "diff.colormoved")) {
|
|
|
|
int cm = parse_color_moved(value);
|
|
|
|
if (cm < 0)
|
|
|
|
return -1;
|
|
|
|
diff_color_moved_default = cm;
|
|
|
|
return 0;
|
|
|
|
}
|
2018-07-19 03:31:56 +08:00
|
|
|
if (!strcmp(var, "diff.colormovedws")) {
|
2018-11-14 05:33:57 +08:00
|
|
|
unsigned cm = parse_color_moved_ws(value);
|
|
|
|
if (cm & COLOR_MOVED_WS_ERROR)
|
2018-07-19 03:31:56 +08:00
|
|
|
return -1;
|
|
|
|
diff_color_moved_ws_default = cm;
|
|
|
|
return 0;
|
|
|
|
}
|
2012-09-28 03:12:52 +08:00
|
|
|
if (!strcmp(var, "diff.context")) {
|
|
|
|
diff_context_default = git_config_int(var, value);
|
|
|
|
if (diff_context_default < 0)
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
2017-01-12 20:21:11 +08:00
|
|
|
if (!strcmp(var, "diff.interhunkcontext")) {
|
|
|
|
diff_interhunk_context_default = git_config_int(var, value);
|
|
|
|
if (diff_interhunk_context_default < 0)
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
2006-07-07 19:01:23 +08:00
|
|
|
if (!strcmp(var, "diff.renames")) {
|
2009-04-10 02:46:15 +08:00
|
|
|
diff_detect_rename_default = git_config_rename(var, value);
|
2006-07-07 19:01:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2007-09-01 04:13:42 +08:00
|
|
|
if (!strcmp(var, "diff.autorefreshindex")) {
|
|
|
|
diff_auto_refresh_index = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-08-19 11:08:09 +08:00
|
|
|
if (!strcmp(var, "diff.mnemonicprefix")) {
|
|
|
|
diff_mnemonic_prefix = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2010-05-03 10:03:41 +08:00
|
|
|
if (!strcmp(var, "diff.noprefix")) {
|
|
|
|
diff_no_prefix = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2020-05-22 18:46:18 +08:00
|
|
|
if (!strcmp(var, "diff.relative")) {
|
|
|
|
diff_relative = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2012-03-01 20:26:46 +08:00
|
|
|
if (!strcmp(var, "diff.statgraphwidth")) {
|
|
|
|
diff_stat_graph_width = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-07-05 13:24:43 +08:00
|
|
|
if (!strcmp(var, "diff.external"))
|
|
|
|
return git_config_string(&external_diff_cmd_cfg, var, value);
|
2009-01-21 11:46:57 +08:00
|
|
|
if (!strcmp(var, "diff.wordregex"))
|
|
|
|
return git_config_string(&diff_word_regex_cfg, var, value);
|
2013-12-19 08:08:12 +08:00
|
|
|
if (!strcmp(var, "diff.orderfile"))
|
|
|
|
return git_config_pathname(&diff_order_file_cfg, var, value);
|
2007-04-23 08:52:55 +08:00
|
|
|
|
2010-08-05 16:49:55 +08:00
|
|
|
if (!strcmp(var, "diff.ignoresubmodules"))
|
|
|
|
handle_ignore_submodules_arg(&default_diff_options, value);
|
|
|
|
|
2012-11-13 23:42:45 +08:00
|
|
|
if (!strcmp(var, "diff.submodule")) {
|
|
|
|
if (parse_submodule_params(&default_diff_options, value))
|
|
|
|
warning(_("Unknown value for 'diff.submodule' config variable: '%s'"),
|
|
|
|
value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-01-16 15:51:57 +08:00
|
|
|
if (!strcmp(var, "diff.algorithm")) {
|
|
|
|
diff_algorithm = parse_algorithm_value(value);
|
|
|
|
if (diff_algorithm < 0)
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-14 01:24:31 +08:00
|
|
|
if (git_color_config(var, value, cb) < 0)
|
|
|
|
return -1;
|
|
|
|
|
2008-05-15 01:46:53 +08:00
|
|
|
return git_diff_basic_config(var, value, cb);
|
2008-01-04 16:59:34 +08:00
|
|
|
}
|
|
|
|
|
2008-05-15 01:46:53 +08:00
|
|
|
int git_diff_basic_config(const char *var, const char *value, void *cb)
|
2008-01-04 16:59:34 +08:00
|
|
|
{
|
use skip_prefix to avoid magic numbers
It's a common idiom to match a prefix and then skip past it
with a magic number, like:
if (starts_with(foo, "bar"))
foo += 3;
This is easy to get wrong, since you have to count the
prefix string yourself, and there's no compiler check if the
string changes. We can use skip_prefix to avoid the magic
numbers here.
Note that some of these conversions could be much shorter.
For example:
if (starts_with(arg, "--foo=")) {
bar = arg + 6;
continue;
}
could become:
if (skip_prefix(arg, "--foo=", &bar))
continue;
However, I have left it as:
if (skip_prefix(arg, "--foo=", &v)) {
bar = v;
continue;
}
to visually match nearby cases which need to actually
process the string. Like:
if (skip_prefix(arg, "--foo=", &v)) {
bar = atoi(v);
continue;
}
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19 03:47:50 +08:00
|
|
|
const char *name;
|
|
|
|
|
2008-08-06 02:27:30 +08:00
|
|
|
if (!strcmp(var, "diff.renamelimit")) {
|
|
|
|
diff_rename_limit_default = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-08 02:23:02 +08:00
|
|
|
if (userdiff_config(var, value) < 0)
|
|
|
|
return -1;
|
2008-10-26 12:45:55 +08:00
|
|
|
|
use skip_prefix to avoid magic numbers
It's a common idiom to match a prefix and then skip past it
with a magic number, like:
if (starts_with(foo, "bar"))
foo += 3;
This is easy to get wrong, since you have to count the
prefix string yourself, and there's no compiler check if the
string changes. We can use skip_prefix to avoid the magic
numbers here.
Note that some of these conversions could be much shorter.
For example:
if (starts_with(arg, "--foo=")) {
bar = arg + 6;
continue;
}
could become:
if (skip_prefix(arg, "--foo=", &bar))
continue;
However, I have left it as:
if (skip_prefix(arg, "--foo=", &v)) {
bar = v;
continue;
}
to visually match nearby cases which need to actually
process the string. Like:
if (skip_prefix(arg, "--foo=", &v)) {
bar = atoi(v);
continue;
}
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19 03:47:50 +08:00
|
|
|
if (skip_prefix(var, "diff.color.", &name) ||
|
|
|
|
skip_prefix(var, "color.diff.", &name)) {
|
|
|
|
int slot = parse_diff_color_slot(name);
|
ignore unknown color configuration
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-12 20:25:24 +08:00
|
|
|
if (slot < 0)
|
|
|
|
return 0;
|
2008-02-12 02:53:56 +08:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2014-10-08 03:33:09 +08:00
|
|
|
return color_parse(value, diff_colors[slot]);
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
}
|
2007-04-23 08:52:55 +08:00
|
|
|
|
2020-01-31 17:57:49 +08:00
|
|
|
if (!strcmp(var, "diff.wserrorhighlight")) {
|
|
|
|
int val = parse_ws_error_highlight(value);
|
|
|
|
if (val < 0)
|
|
|
|
return -1;
|
|
|
|
ws_error_highlight_default = val;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-08-15 19:39:26 +08:00
|
|
|
/* like GNU diff's --suppress-blank-empty option */
|
2009-01-21 05:08:33 +08:00
|
|
|
if (!strcmp(var, "diff.suppressblankempty") ||
|
|
|
|
/* for backwards compatibility */
|
|
|
|
!strcmp(var, "diff.suppress-blank-empty")) {
|
2008-08-15 19:39:26 +08:00
|
|
|
diff_suppress_blank_empty = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-04-29 17:36:19 +08:00
|
|
|
if (!strcmp(var, "diff.dirstat")) {
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
struct strbuf errmsg = STRBUF_INIT;
|
2011-04-29 17:36:20 +08:00
|
|
|
default_diff_options.dirstat_permille = diff_dirstat_permille_default;
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
if (parse_dirstat_params(&default_diff_options, value, &errmsg))
|
2011-04-29 17:36:23 +08:00
|
|
|
warning(_("Found errors in 'diff.dirstat' config variable:\n%s"),
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
errmsg.buf);
|
|
|
|
strbuf_release(&errmsg);
|
2011-04-29 17:36:20 +08:00
|
|
|
diff_dirstat_permille_default = default_diff_options.dirstat_permille;
|
2011-04-29 17:36:19 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-05-09 00:03:36 +08:00
|
|
|
if (git_diff_heuristic_config(var, value, cb) < 0)
|
|
|
|
return -1;
|
|
|
|
|
2011-08-18 13:05:08 +08:00
|
|
|
return git_default_config(var, value, cb);
|
diff --color: use $GIT_DIR/config
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 19:06:23 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static char *quote_two(const char *one, const char *two)
|
|
|
|
{
|
2020-09-11 01:01:59 +08:00
|
|
|
int need_one = quote_c_style(one, NULL, NULL, CQUOTE_NODQ);
|
|
|
|
int need_two = quote_c_style(two, NULL, NULL, CQUOTE_NODQ);
|
2008-10-10 03:12:12 +08:00
|
|
|
struct strbuf res = STRBUF_INIT;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (need_one + need_two) {
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
strbuf_addch(&res, '"');
|
2020-09-11 01:01:59 +08:00
|
|
|
quote_c_style(one, &res, NULL, CQUOTE_NODQ);
|
|
|
|
quote_c_style(two, &res, NULL, CQUOTE_NODQ);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
strbuf_addch(&res, '"');
|
|
|
|
} else {
|
|
|
|
strbuf_addstr(&res, one);
|
|
|
|
strbuf_addstr(&res, two);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2007-09-27 18:58:23 +08:00
|
|
|
return strbuf_detach(&res, NULL);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char *external_diff(void)
|
|
|
|
{
|
|
|
|
static const char *external_diff_cmd = NULL;
|
|
|
|
static int done_preparing = 0;
|
|
|
|
|
|
|
|
if (done_preparing)
|
|
|
|
return external_diff_cmd;
|
2019-01-12 04:26:08 +08:00
|
|
|
external_diff_cmd = xstrdup_or_null(getenv("GIT_EXTERNAL_DIFF"));
|
2007-12-17 21:42:20 +08:00
|
|
|
if (!external_diff_cmd)
|
|
|
|
external_diff_cmd = external_diff_cmd_cfg;
|
2006-04-22 14:57:45 +08:00
|
|
|
done_preparing = 1;
|
|
|
|
return external_diff_cmd;
|
|
|
|
}
|
|
|
|
|
2015-08-13 01:12:01 +08:00
|
|
|
/*
|
|
|
|
* Keep track of files used for diffing. Sometimes such an entry
|
|
|
|
* refers to a temporary file, sometimes to an existing file, and
|
|
|
|
* sometimes to "/dev/null".
|
|
|
|
*/
|
2006-04-22 14:57:45 +08:00
|
|
|
static struct diff_tempfile {
|
2015-08-13 01:12:01 +08:00
|
|
|
/*
|
|
|
|
* filename external diff should read from, or NULL if this
|
|
|
|
* entry is currently not in use:
|
|
|
|
*/
|
|
|
|
const char *name;
|
|
|
|
|
2017-03-27 00:01:24 +08:00
|
|
|
char hex[GIT_MAX_HEXSZ + 1];
|
2006-04-22 14:57:45 +08:00
|
|
|
char mode[10];
|
2015-08-13 01:12:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If this diff_tempfile instance refers to a temporary file,
|
|
|
|
* this tempfile object is used to manage its lifetime.
|
|
|
|
*/
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
struct tempfile *tempfile;
|
2006-04-22 14:57:45 +08:00
|
|
|
} diff_temp[2];
|
|
|
|
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
struct emit_callback {
|
|
|
|
int color_diff;
|
|
|
|
unsigned ws_rule;
|
|
|
|
int blank_at_eof_in_preimage;
|
|
|
|
int blank_at_eof_in_postimage;
|
|
|
|
int lno_in_preimage;
|
|
|
|
int lno_in_postimage;
|
|
|
|
const char **label_path;
|
|
|
|
struct diff_words_data *diff_words;
|
2010-05-26 15:08:02 +08:00
|
|
|
struct diff_options *opt;
|
2009-11-20 05:12:24 +08:00
|
|
|
struct strbuf *header;
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
};
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static int count_lines(const char *data, int size)
|
|
|
|
{
|
|
|
|
int count, ch, completely_empty = 1, nl_just_seen = 0;
|
|
|
|
count = 0;
|
|
|
|
while (0 < size--) {
|
|
|
|
ch = *data++;
|
|
|
|
if (ch == '\n') {
|
|
|
|
count++;
|
|
|
|
nl_just_seen = 1;
|
|
|
|
completely_empty = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
nl_just_seen = 0;
|
|
|
|
completely_empty = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (completely_empty)
|
|
|
|
return 0;
|
|
|
|
if (!nl_just_seen)
|
|
|
|
count++; /* no trailing newline */
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static int fill_mmfile(struct repository *r, mmfile_t *mf,
|
|
|
|
struct diff_filespec *one)
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one)) {
|
|
|
|
mf->ptr = (char *)""; /* does not matter */
|
|
|
|
mf->size = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
2020-04-08 06:11:41 +08:00
|
|
|
else if (diff_populate_filespec(r, one, NULL))
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
return -1;
|
2009-09-15 18:38:30 +08:00
|
|
|
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
mf->ptr = one->data;
|
|
|
|
mf->size = one->size;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-02-19 16:16:32 +08:00
|
|
|
/* like fill_mmfile, but only for size, so we can avoid retrieving blob */
|
2018-09-21 23:57:19 +08:00
|
|
|
static unsigned long diff_filespec_size(struct repository *r,
|
|
|
|
struct diff_filespec *one)
|
2011-02-19 16:16:32 +08:00
|
|
|
{
|
2020-04-08 06:11:41 +08:00
|
|
|
struct diff_populate_filespec_options dpf_options = {
|
|
|
|
.check_size_only = 1,
|
|
|
|
};
|
|
|
|
|
2011-02-19 16:16:32 +08:00
|
|
|
if (!DIFF_FILE_VALID(one))
|
|
|
|
return 0;
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(r, one, &dpf_options);
|
2011-02-19 16:16:32 +08:00
|
|
|
return one->size;
|
|
|
|
}
|
|
|
|
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
static int count_trailing_blank(mmfile_t *mf, unsigned ws_rule)
|
|
|
|
{
|
|
|
|
char *ptr = mf->ptr;
|
|
|
|
long size = mf->size;
|
|
|
|
int cnt = 0;
|
|
|
|
|
|
|
|
if (!size)
|
|
|
|
return cnt;
|
|
|
|
ptr += size - 1; /* pointing at the very end */
|
|
|
|
if (*ptr != '\n')
|
|
|
|
; /* incomplete line */
|
|
|
|
else
|
|
|
|
ptr--; /* skip the last LF */
|
|
|
|
while (mf->ptr < ptr) {
|
|
|
|
char *prev_eol;
|
|
|
|
for (prev_eol = ptr; mf->ptr <= prev_eol; prev_eol--)
|
|
|
|
if (*prev_eol == '\n')
|
|
|
|
break;
|
|
|
|
if (!ws_blank_line(prev_eol + 1, ptr - prev_eol, ws_rule))
|
|
|
|
break;
|
|
|
|
cnt++;
|
|
|
|
ptr = prev_eol - 1;
|
|
|
|
}
|
|
|
|
return cnt;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void check_blank_at_eof(mmfile_t *mf1, mmfile_t *mf2,
|
|
|
|
struct emit_callback *ecbdata)
|
|
|
|
{
|
|
|
|
int l1, l2, at;
|
|
|
|
unsigned ws_rule = ecbdata->ws_rule;
|
|
|
|
l1 = count_trailing_blank(mf1, ws_rule);
|
|
|
|
l2 = count_trailing_blank(mf2, ws_rule);
|
|
|
|
if (l2 <= l1) {
|
|
|
|
ecbdata->blank_at_eof_in_preimage = 0;
|
|
|
|
ecbdata->blank_at_eof_in_postimage = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
at = count_lines(mf1->ptr, mf1->size);
|
|
|
|
ecbdata->blank_at_eof_in_preimage = (at - l1) + 1;
|
|
|
|
|
|
|
|
at = count_lines(mf2->ptr, mf2->size);
|
|
|
|
ecbdata->blank_at_eof_in_postimage = (at - l2) + 1;
|
|
|
|
}
|
|
|
|
|
2018-08-13 19:33:20 +08:00
|
|
|
static void emit_line_0(struct diff_options *o,
|
2018-08-14 09:41:19 +08:00
|
|
|
const char *set_sign, const char *set, unsigned reverse, const char *reset,
|
2009-09-15 09:44:01 +08:00
|
|
|
int first, const char *line, int len)
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
{
|
|
|
|
int has_trailing_newline, has_trailing_carriage_return;
|
2018-08-14 09:41:22 +08:00
|
|
|
int needs_reset = 0; /* at the end of the line */
|
2010-05-26 15:08:02 +08:00
|
|
|
FILE *file = o->file;
|
|
|
|
|
2018-08-14 09:41:21 +08:00
|
|
|
fputs(diff_line_prefix(o), file);
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
|
2018-08-14 09:41:22 +08:00
|
|
|
has_trailing_newline = (len > 0 && line[len-1] == '\n');
|
|
|
|
if (has_trailing_newline)
|
|
|
|
len--;
|
|
|
|
|
|
|
|
has_trailing_carriage_return = (len > 0 && line[len-1] == '\r');
|
|
|
|
if (has_trailing_carriage_return)
|
|
|
|
len--;
|
|
|
|
|
|
|
|
if (!len && !first)
|
|
|
|
goto end_of_line;
|
|
|
|
|
|
|
|
if (reverse && want_color(o->use_color)) {
|
|
|
|
fputs(GIT_COLOR_REVERSE, file);
|
|
|
|
needs_reset = 1;
|
2009-09-15 09:44:01 +08:00
|
|
|
}
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
|
2018-08-14 09:41:22 +08:00
|
|
|
if (set_sign) {
|
|
|
|
fputs(set_sign, file);
|
|
|
|
needs_reset = 1;
|
2009-11-28 14:04:10 +08:00
|
|
|
}
|
2018-08-14 09:41:22 +08:00
|
|
|
|
|
|
|
if (first)
|
|
|
|
fputc(first, file);
|
|
|
|
|
|
|
|
if (!len)
|
|
|
|
goto end_of_line;
|
|
|
|
|
|
|
|
if (set) {
|
|
|
|
if (set_sign && set != set_sign)
|
|
|
|
fputs(reset, file);
|
2009-11-28 14:04:10 +08:00
|
|
|
fputs(set, file);
|
2018-08-14 09:41:22 +08:00
|
|
|
needs_reset = 1;
|
2009-11-28 14:04:10 +08:00
|
|
|
}
|
2018-08-14 09:41:22 +08:00
|
|
|
fwrite(line, len, 1, file);
|
|
|
|
needs_reset = 1; /* 'line' may contain color codes. */
|
|
|
|
|
|
|
|
end_of_line:
|
|
|
|
if (needs_reset)
|
|
|
|
fputs(reset, file);
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
if (has_trailing_carriage_return)
|
|
|
|
fputc('\r', file);
|
|
|
|
if (has_trailing_newline)
|
|
|
|
fputc('\n', file);
|
|
|
|
}
|
|
|
|
|
2010-05-26 15:08:02 +08:00
|
|
|
static void emit_line(struct diff_options *o, const char *set, const char *reset,
|
2009-09-15 09:44:01 +08:00
|
|
|
const char *line, int len)
|
|
|
|
{
|
2018-08-14 09:41:22 +08:00
|
|
|
emit_line_0(o, set, NULL, 0, reset, 0, line, len);
|
2009-09-15 09:44:01 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:06:49 +08:00
|
|
|
enum diff_symbol {
|
2017-06-30 08:07:01 +08:00
|
|
|
DIFF_SYMBOL_BINARY_DIFF_HEADER,
|
|
|
|
DIFF_SYMBOL_BINARY_DIFF_HEADER_DELTA,
|
|
|
|
DIFF_SYMBOL_BINARY_DIFF_HEADER_LITERAL,
|
|
|
|
DIFF_SYMBOL_BINARY_DIFF_BODY,
|
|
|
|
DIFF_SYMBOL_BINARY_DIFF_FOOTER,
|
2017-06-30 08:07:02 +08:00
|
|
|
DIFF_SYMBOL_STATS_SUMMARY_NO_FILES,
|
|
|
|
DIFF_SYMBOL_STATS_SUMMARY_ABBREV,
|
|
|
|
DIFF_SYMBOL_STATS_SUMMARY_INSERTS_DELETES,
|
|
|
|
DIFF_SYMBOL_STATS_LINE,
|
2017-06-30 08:07:03 +08:00
|
|
|
DIFF_SYMBOL_WORD_DIFF,
|
2017-06-30 08:07:04 +08:00
|
|
|
DIFF_SYMBOL_STAT_SEP,
|
2017-06-30 08:07:05 +08:00
|
|
|
DIFF_SYMBOL_SUMMARY,
|
2017-06-30 08:07:00 +08:00
|
|
|
DIFF_SYMBOL_SUBMODULE_ADD,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_DEL,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_UNTRACKED,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_MODIFIED,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_HEADER,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_ERROR,
|
|
|
|
DIFF_SYMBOL_SUBMODULE_PIPETHROUGH,
|
2017-06-30 08:06:59 +08:00
|
|
|
DIFF_SYMBOL_REWRITE_DIFF,
|
2017-06-30 08:06:58 +08:00
|
|
|
DIFF_SYMBOL_BINARY_FILES,
|
2017-06-30 08:06:57 +08:00
|
|
|
DIFF_SYMBOL_HEADER,
|
2017-06-30 08:06:56 +08:00
|
|
|
DIFF_SYMBOL_FILEPAIR_PLUS,
|
|
|
|
DIFF_SYMBOL_FILEPAIR_MINUS,
|
2017-06-30 08:06:54 +08:00
|
|
|
DIFF_SYMBOL_WORDS_PORCELAIN,
|
|
|
|
DIFF_SYMBOL_WORDS,
|
2017-06-30 08:06:53 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT,
|
2017-06-30 08:06:55 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT_INCOMPLETE,
|
2017-06-30 08:06:53 +08:00
|
|
|
DIFF_SYMBOL_PLUS,
|
|
|
|
DIFF_SYMBOL_MINUS,
|
2017-06-30 08:06:52 +08:00
|
|
|
DIFF_SYMBOL_NO_LF_EOF,
|
2017-06-30 08:06:51 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT_FRAGINFO,
|
2017-06-30 08:06:50 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT_MARKER,
|
2017-06-30 08:06:49 +08:00
|
|
|
DIFF_SYMBOL_SEPARATOR
|
|
|
|
};
|
2017-06-30 08:06:53 +08:00
|
|
|
/*
|
|
|
|
* Flags for content lines:
|
|
|
|
* 0..12 are whitespace rules
|
|
|
|
* 13-15 are WSEH_NEW | WSEH_OLD | WSEH_CONTEXT
|
|
|
|
* 16 is marking if the line is blank at EOF
|
|
|
|
*/
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
#define DIFF_SYMBOL_CONTENT_BLANK_LINE_EOF (1<<16)
|
|
|
|
#define DIFF_SYMBOL_MOVED_LINE (1<<17)
|
|
|
|
#define DIFF_SYMBOL_MOVED_LINE_ALT (1<<18)
|
2017-07-01 04:53:09 +08:00
|
|
|
#define DIFF_SYMBOL_MOVED_LINE_UNINTERESTING (1<<19)
|
2017-06-30 08:06:53 +08:00
|
|
|
#define DIFF_SYMBOL_CONTENT_WS_MASK (WSEH_NEW | WSEH_OLD | WSEH_CONTEXT | WS_RULE_MASK)
|
|
|
|
|
2017-06-30 08:07:06 +08:00
|
|
|
/*
|
|
|
|
* This struct is used when we need to buffer the output of the diff output.
|
|
|
|
*
|
|
|
|
* NEEDSWORK: Instead of storing a copy of the line, add an offset pointer
|
|
|
|
* into the pre/post image file. This pointer could be a union with the
|
|
|
|
* line pointer. By storing an offset into the file instead of the literal line,
|
|
|
|
* we can decrease the memory footprint for the buffered output. At first we
|
|
|
|
* may want to only have indirection for the content lines, but we could also
|
|
|
|
* enhance the state for emitting prefabricated lines, e.g. the similarity
|
|
|
|
* score line or hunk/file headers would only need to store a number or path
|
|
|
|
* and then the output can be constructed later on depending on state.
|
|
|
|
*/
|
|
|
|
struct emitted_diff_symbol {
|
|
|
|
const char *line;
|
|
|
|
int len;
|
|
|
|
int flags;
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
int indent_off; /* Offset to first non-whitespace character */
|
|
|
|
int indent_width; /* The visual width of the indentation */
|
2021-12-09 18:30:09 +08:00
|
|
|
unsigned id;
|
2017-06-30 08:07:06 +08:00
|
|
|
enum diff_symbol s;
|
|
|
|
};
|
2021-09-27 20:54:25 +08:00
|
|
|
#define EMITTED_DIFF_SYMBOL_INIT { 0 }
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
struct emitted_diff_symbols {
|
|
|
|
struct emitted_diff_symbol *buf;
|
|
|
|
int nr, alloc;
|
|
|
|
};
|
2021-09-27 20:54:25 +08:00
|
|
|
#define EMITTED_DIFF_SYMBOLS_INIT { 0 }
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
static void append_emitted_diff_symbol(struct diff_options *o,
|
|
|
|
struct emitted_diff_symbol *e)
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
{
|
2017-06-30 08:07:06 +08:00
|
|
|
struct emitted_diff_symbol *f;
|
|
|
|
|
|
|
|
ALLOC_GROW(o->emitted_symbols->buf,
|
|
|
|
o->emitted_symbols->nr + 1,
|
|
|
|
o->emitted_symbols->alloc);
|
|
|
|
f = &o->emitted_symbols->buf[o->emitted_symbols->nr++];
|
|
|
|
|
|
|
|
memcpy(f, e, sizeof(struct emitted_diff_symbol));
|
|
|
|
f->line = e->line ? xmemdupz(e->line, e->len) : NULL;
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
}
|
|
|
|
|
diff.c: fix a double-free regression in a18d66cefb
My a18d66cefb9 (diff.c: free "buf" in diff_words_flush(), 2022-03-04)
has what it retrospect is a rather obvious bug (I don't know what I
was thinking, if it all): We use the "emitted_symbols" allocation in
append_emitted_diff_symbol() N times, but starting with a18d66cefb9
we'd free it after its first use!
The correct way to free this data would have been to add the free() to
the existing free_diff_words_data() function, so let's do that. The
"ecbdata->diff_words->opt->emitted_symbols" might be NULL, so let's
add a trivial free_emitted_diff_symbols() helper next to the function
that appends to it.
This fixes the "no effect on show from" leak tested for in the
preceding commit. Perhaps confusingly this change will skip that test
under SANITIZE=leak, but otherwise opt-in the
"t4015-diff-whitespace.sh" test.
The reason is that a18d66cefb9 "fixed" the leak in the preceding "no
effect on diff" test, but for the first call to diff_words_flush() the
"wol->buf" would be NULL, so we wouldn't double-free (and
SANITIZE=address would see nothing amiss). With this change we'll
still pass that test, showing that we've also fixed leaks on this
codepath.
We then have to skip the new "no effect on show" test because it
happens to trip over an unrelated memory leak (in revision.c). The
same goes for "move detection with submodules". Both of them pass with
SANITIZE=address though, which would error on the "no effect on show"
test before this change.
Reported-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17 22:55:35 +08:00
|
|
|
static void free_emitted_diff_symbols(struct emitted_diff_symbols *e)
|
|
|
|
{
|
|
|
|
if (!e)
|
|
|
|
return;
|
|
|
|
free(e->buf);
|
|
|
|
free(e);
|
|
|
|
}
|
|
|
|
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
struct moved_entry {
|
|
|
|
const struct emitted_diff_symbol *es;
|
|
|
|
struct moved_entry *next_line;
|
2021-12-09 18:30:09 +08:00
|
|
|
struct moved_entry *next_match;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
};
|
|
|
|
|
2018-10-04 18:07:41 +08:00
|
|
|
struct moved_block {
|
|
|
|
struct moved_entry *match;
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
int wsd; /* The whitespace delta of this block */
|
2018-10-04 18:07:41 +08:00
|
|
|
};
|
|
|
|
|
2018-11-23 19:16:58 +08:00
|
|
|
#define INDENT_BLANKLINE INT_MIN
|
|
|
|
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
static void fill_es_indent_data(struct emitted_diff_symbol *es)
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
{
|
2018-11-23 19:16:58 +08:00
|
|
|
unsigned int off = 0, i;
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
int width = 0, tab_width = es->flags & WS_TAB_WIDTH_MASK;
|
|
|
|
const char *s = es->line;
|
|
|
|
const int len = es->len;
|
|
|
|
|
|
|
|
/* skip any \v \f \r at start of indentation */
|
|
|
|
while (s[off] == '\f' || s[off] == '\v' ||
|
|
|
|
(s[off] == '\r' && off < len - 1))
|
|
|
|
off++;
|
|
|
|
|
|
|
|
/* calculate the visual width of indentation */
|
|
|
|
while(1) {
|
|
|
|
if (s[off] == ' ') {
|
|
|
|
width++;
|
|
|
|
off++;
|
|
|
|
} else if (s[off] == '\t') {
|
|
|
|
width += tab_width - (width % tab_width);
|
|
|
|
while (s[++off] == '\t')
|
|
|
|
width += tab_width;
|
|
|
|
} else {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-23 19:16:58 +08:00
|
|
|
/* check if this line is blank */
|
|
|
|
for (i = off; i < len; i++)
|
|
|
|
if (!isspace(s[i]))
|
|
|
|
break;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2018-11-23 19:16:58 +08:00
|
|
|
if (i == len) {
|
|
|
|
es->indent_width = INDENT_BLANKLINE;
|
|
|
|
es->indent_off = len;
|
|
|
|
} else {
|
|
|
|
es->indent_off = off;
|
|
|
|
es->indent_width = width;
|
|
|
|
}
|
2018-10-04 18:07:41 +08:00
|
|
|
}
|
|
|
|
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
static int compute_ws_delta(const struct emitted_diff_symbol *a,
|
2021-12-09 18:30:07 +08:00
|
|
|
const struct emitted_diff_symbol *b)
|
|
|
|
{
|
|
|
|
int a_width = a->indent_width,
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
b_width = b->indent_width;
|
|
|
|
|
2021-12-09 18:30:07 +08:00
|
|
|
if (a_width == INDENT_BLANKLINE && b_width == INDENT_BLANKLINE)
|
|
|
|
return INDENT_BLANKLINE;
|
2018-10-04 18:07:43 +08:00
|
|
|
|
2021-12-09 18:30:07 +08:00
|
|
|
return a_width - b_width;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:30:02 +08:00
|
|
|
static int cmp_in_block_with_wsd(const struct moved_entry *cur,
|
|
|
|
const struct emitted_diff_symbol *l,
|
|
|
|
struct moved_block *pmb)
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
{
|
2021-12-09 18:30:09 +08:00
|
|
|
int a_width = cur->es->indent_width, b_width = l->indent_width;
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
int delta;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
/* The text of each line must match */
|
|
|
|
if (cur->es->id != l->id)
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
return 1;
|
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
/*
|
|
|
|
* If 'l' and 'cur' are both blank then we don't need to check the
|
|
|
|
* indent. We only need to check cur as we know the strings match.
|
|
|
|
* */
|
|
|
|
if (a_width == INDENT_BLANKLINE)
|
2018-11-23 19:16:58 +08:00
|
|
|
return 0;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
|
|
|
/*
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
* The indent changes of the block are known and stored in pmb->wsd;
|
|
|
|
* however we need to check if the indent changes of the current line
|
2021-12-09 18:30:09 +08:00
|
|
|
* match those of the current block.
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
*/
|
2021-12-09 18:30:02 +08:00
|
|
|
delta = b_width - a_width;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2018-11-23 19:16:58 +08:00
|
|
|
/*
|
|
|
|
* If the previous lines of this block were all blank then set its
|
|
|
|
* whitespace delta.
|
|
|
|
*/
|
|
|
|
if (pmb->wsd == INDENT_BLANKLINE)
|
|
|
|
pmb->wsd = delta;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
return delta != pmb->wsd;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
struct interned_diff_symbol {
|
|
|
|
struct hashmap_entry ent;
|
|
|
|
struct emitted_diff_symbol *es;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int interned_diff_symbol_cmp(const void *hashmap_cmp_fn_data,
|
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
|
|
|
const void *keydata)
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
{
|
2018-07-17 07:05:38 +08:00
|
|
|
const struct diff_options *diffopt = hashmap_cmp_fn_data;
|
2021-12-09 18:30:07 +08:00
|
|
|
const struct emitted_diff_symbol *a, *b;
|
2018-07-17 07:05:40 +08:00
|
|
|
unsigned flags = diffopt->color_moved_ws_handling
|
|
|
|
& XDF_WHITESPACE_FLAGS;
|
2018-07-17 07:05:38 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
a = container_of(eptr, const struct interned_diff_symbol, ent)->es;
|
|
|
|
b = container_of(entry_or_key, const struct interned_diff_symbol, ent)->es;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2021-12-09 18:30:07 +08:00
|
|
|
return !xdiff_compare_lines(a->line + a->indent_off,
|
|
|
|
a->len - a->indent_off,
|
|
|
|
b->line + b->indent_off,
|
|
|
|
b->len - b->indent_off, flags);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
static void prepare_entry(struct diff_options *o, struct emitted_diff_symbol *l,
|
|
|
|
struct interned_diff_symbol *s)
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
{
|
2018-07-17 07:05:40 +08:00
|
|
|
unsigned flags = o->color_moved_ws_handling & XDF_WHITESPACE_FLAGS;
|
2021-12-09 18:30:07 +08:00
|
|
|
unsigned int hash = xdiff_hash_string(l->line + l->indent_off,
|
|
|
|
l->len - l->indent_off, flags);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
hashmap_entry_init(&s->ent, hash);
|
|
|
|
s->es = l;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
struct moved_entry_list {
|
|
|
|
struct moved_entry *add, *del;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct moved_entry_list *add_lines_to_move_detection(struct diff_options *o,
|
|
|
|
struct mem_pool *entry_mem_pool)
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
{
|
|
|
|
struct moved_entry *prev_line = NULL;
|
2021-12-09 18:30:09 +08:00
|
|
|
struct mem_pool interned_pool;
|
|
|
|
struct hashmap interned_map;
|
|
|
|
struct moved_entry_list *entry_list = NULL;
|
|
|
|
size_t entry_list_alloc = 0;
|
|
|
|
unsigned id = 0;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
int n;
|
2021-12-09 18:30:09 +08:00
|
|
|
|
|
|
|
hashmap_init(&interned_map, interned_diff_symbol_cmp, o, 8096);
|
|
|
|
mem_pool_init(&interned_pool, 1024 * 1024);
|
|
|
|
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
for (n = 0; n < o->emitted_symbols->nr; n++) {
|
2021-12-09 18:30:09 +08:00
|
|
|
struct interned_diff_symbol key;
|
|
|
|
struct emitted_diff_symbol *l = &o->emitted_symbols->buf[n];
|
|
|
|
struct interned_diff_symbol *s;
|
|
|
|
struct moved_entry *entry;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
if (l->s != DIFF_SYMBOL_PLUS && l->s != DIFF_SYMBOL_MINUS) {
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
prev_line = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
diff --color-moved-ws: modify allow-indentation-change
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377 ("convert.h: drop 'extern' from function
declaration", 2018-06-30) the function parameters in the following
lines are not colored as moved [1].
-extern int stream_filter(struct stream_filter *,
- const char *input, size_t *isize_p,
- char *output, size_t *osize_p);
+int stream_filter(struct stream_filter *,
+ const char *input, size_t *isize_p,
+ char *output, size_t *osize_p);
This commit changes the way the indentation is handled to track the
visual size of the indentation rather than the characters in the
indentation. This has the benefit that any whitespace errors do not
interfer with the move detection (the whitespace errors will still be
highlighted according to --ws-error-highlight). During the discussion
of this feature there were concerns about the correct detection of
indentation for python. However those concerns apply whether or not
we're detecting moved lines so no attempt is made to determine if the
indentation is 'pythonic'.
[1] Note that before the commit to fix the erroneous coloring of moved
lines each line was colored as a different block, since that commit
they are uncolored.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-23 19:16:57 +08:00
|
|
|
if (o->color_moved_ws_handling &
|
|
|
|
COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE)
|
2021-12-09 18:30:09 +08:00
|
|
|
fill_es_indent_data(l);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
prepare_entry(o, l, &key);
|
|
|
|
s = hashmap_get_entry(&interned_map, &key, ent, &key.ent);
|
|
|
|
if (s) {
|
|
|
|
l->id = s->es->id;
|
|
|
|
} else {
|
|
|
|
l->id = id;
|
|
|
|
ALLOC_GROW_BY(entry_list, id, 1, entry_list_alloc);
|
|
|
|
hashmap_add(&interned_map,
|
|
|
|
memcpy(mem_pool_alloc(&interned_pool,
|
|
|
|
sizeof(key)),
|
|
|
|
&key, sizeof(key)));
|
|
|
|
}
|
|
|
|
entry = mem_pool_alloc(entry_mem_pool, sizeof(*entry));
|
|
|
|
entry->es = l;
|
|
|
|
entry->next_line = NULL;
|
|
|
|
if (prev_line && prev_line->es->s == l->s)
|
|
|
|
prev_line->next_line = entry;
|
|
|
|
prev_line = entry;
|
|
|
|
if (l->s == DIFF_SYMBOL_PLUS) {
|
|
|
|
entry->next_match = entry_list[l->id].add;
|
|
|
|
entry_list[l->id].add = entry;
|
|
|
|
} else {
|
|
|
|
entry->next_match = entry_list[l->id].del;
|
|
|
|
entry_list[l->id].del = entry;
|
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
2021-12-09 18:30:09 +08:00
|
|
|
|
|
|
|
hashmap_clear(&interned_map);
|
|
|
|
mem_pool_discard(&interned_pool, 0);
|
|
|
|
|
|
|
|
return entry_list;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2018-07-17 07:05:41 +08:00
|
|
|
static void pmb_advance_or_null(struct diff_options *o,
|
2021-12-09 18:30:03 +08:00
|
|
|
struct emitted_diff_symbol *l,
|
2018-10-04 18:07:41 +08:00
|
|
|
struct moved_block *pmb,
|
2021-12-09 18:30:05 +08:00
|
|
|
int *pmb_nr)
|
2018-07-17 07:05:41 +08:00
|
|
|
{
|
2021-12-09 18:30:05 +08:00
|
|
|
int i, j;
|
2021-12-09 18:30:03 +08:00
|
|
|
|
2021-12-09 18:30:05 +08:00
|
|
|
for (i = 0, j = 0; i < *pmb_nr; i++) {
|
2021-12-09 18:30:04 +08:00
|
|
|
int match;
|
2018-10-04 18:07:41 +08:00
|
|
|
struct moved_entry *prev = pmb[i].match;
|
2018-07-17 07:05:41 +08:00
|
|
|
struct moved_entry *cur = (prev && prev->next_line) ?
|
|
|
|
prev->next_line : NULL;
|
|
|
|
|
2021-12-09 18:30:04 +08:00
|
|
|
if (o->color_moved_ws_handling &
|
|
|
|
COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE)
|
|
|
|
match = cur &&
|
|
|
|
!cmp_in_block_with_wsd(cur, l, &pmb[i]);
|
|
|
|
else
|
2021-12-09 18:30:09 +08:00
|
|
|
match = cur && cur->es->id == l->id;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
|
2021-12-09 18:30:05 +08:00
|
|
|
if (match) {
|
|
|
|
pmb[j] = pmb[i];
|
|
|
|
pmb[j++].match = cur;
|
2018-09-04 21:52:58 +08:00
|
|
|
}
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
}
|
2021-12-09 18:30:05 +08:00
|
|
|
*pmb_nr = j;
|
diff.c: add white space mode to move detection that allows indent changes
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To just review the moved code ignoring the change in indentation, a mode
to ignore spaces in the move detection as implemented in a previous patch
would be enough. However the whole move coloring as motivated in commit
2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
up the notion of the reviewer being able to trust the move of a "block".
As there are languages such as python, which depend on proper relative
indentation for the control flow of the program, ignoring any white space
change in a block would not uphold the promises of 2e2d5ac that allows
reviewers to pay less attention to the inside of a block, as inside
the reviewer wants to assume the same program flow.
This new mode of white space ignorance will take this into account and will
only allow the same white space changes per line in each block. This patch
even allows only for the same change at the beginning of the lines.
As this is a white space mode, it is made exclusive to other white space
modes in the move detection.
This patch brings some challenges, related to the detection of blocks.
We need a wide net to catch the possible moved lines, but then need to
narrow down to check if the blocks are still intact. Consider this
example (ignoring block sizes):
- A
- B
- C
+ A
+ B
+ C
At the beginning of a block when checking if there is a counterpart
for A, we have to ignore all space changes. However at the following
lines we have to check if the indent change stayed the same.
Checking if the indentation change did stay the same, is done by computing
the indentation change by the difference in line length, and then assume
the change is only in the beginning of the longer line, the common tail
is the same. That is why the test contains lines like:
- <TAB> A
...
+ A <TAB>
...
As the first line starting a block is caught using a compare function that
ignores white spaces unlike the rest of the block, where the white space
delta is taken into account for the comparison, we also have to think about
the following situation:
- A
- B
- A
- B
+ A
+ B
+ A
+ B
When checking if the first A (both in the + and - lines) is a start of
a block, we have to check all 'A' and record all the white space deltas
such that we can find the example above to be just one block that is
indented.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-19 03:31:55 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:29:57 +08:00
|
|
|
static void fill_potential_moved_blocks(struct diff_options *o,
|
|
|
|
struct moved_entry *match,
|
|
|
|
struct emitted_diff_symbol *l,
|
|
|
|
struct moved_block **pmb_p,
|
|
|
|
int *pmb_alloc_p, int *pmb_nr_p)
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:29:57 +08:00
|
|
|
{
|
|
|
|
struct moved_block *pmb = *pmb_p;
|
|
|
|
int pmb_alloc = *pmb_alloc_p, pmb_nr = *pmb_nr_p;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:29:57 +08:00
|
|
|
/*
|
|
|
|
* The current line is the start of a new block.
|
|
|
|
* Setup the set of potential blocks.
|
|
|
|
*/
|
2021-12-09 18:30:09 +08:00
|
|
|
for (; match; match = match->next_match) {
|
2021-12-09 18:29:57 +08:00
|
|
|
ALLOC_GROW(pmb, pmb_nr + 1, pmb_alloc);
|
|
|
|
if (o->color_moved_ws_handling &
|
2021-12-09 18:30:07 +08:00
|
|
|
COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE)
|
|
|
|
pmb[pmb_nr].wsd = compute_ws_delta(l, match->es);
|
|
|
|
else
|
2021-12-09 18:29:57 +08:00
|
|
|
pmb[pmb_nr].wsd = 0;
|
2021-12-09 18:30:07 +08:00
|
|
|
pmb[pmb_nr++].match = match;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:29:57 +08:00
|
|
|
*pmb_p = pmb;
|
|
|
|
*pmb_alloc_p = pmb_alloc;
|
|
|
|
*pmb_nr_p = pmb_nr;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2017-08-16 09:27:38 +08:00
|
|
|
/*
|
|
|
|
* If o->color_moved is COLOR_MOVED_PLAIN, this function does nothing.
|
|
|
|
*
|
2017-08-16 09:27:39 +08:00
|
|
|
* Otherwise, if the last block has fewer alphanumeric characters than
|
|
|
|
* COLOR_MOVED_MIN_ALNUM_COUNT, unset DIFF_SYMBOL_MOVED_LINE on all lines in
|
2017-08-16 09:27:38 +08:00
|
|
|
* that block.
|
|
|
|
*
|
|
|
|
* The last block consists of the (n - block_length)'th line up to but not
|
|
|
|
* including the nth line.
|
2017-08-16 09:27:39 +08:00
|
|
|
*
|
2018-11-23 19:16:55 +08:00
|
|
|
* Returns 0 if the last block is empty or is unset by this function, non zero
|
|
|
|
* otherwise.
|
|
|
|
*
|
2017-08-16 09:27:39 +08:00
|
|
|
* NEEDSWORK: This uses the same heuristic as blame_entry_score() in blame.c.
|
|
|
|
* Think of a way to unify them.
|
2017-08-16 09:27:38 +08:00
|
|
|
*/
|
2021-12-09 18:29:56 +08:00
|
|
|
#define DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK \
|
|
|
|
(DIFF_SYMBOL_MOVED_LINE | DIFF_SYMBOL_MOVED_LINE_ALT)
|
2018-11-23 19:16:55 +08:00
|
|
|
static int adjust_last_block(struct diff_options *o, int n, int block_length)
|
2017-08-16 09:27:38 +08:00
|
|
|
{
|
2017-08-16 09:27:39 +08:00
|
|
|
int i, alnum_count = 0;
|
|
|
|
if (o->color_moved == COLOR_MOVED_PLAIN)
|
2018-11-23 19:16:55 +08:00
|
|
|
return block_length;
|
2017-08-16 09:27:39 +08:00
|
|
|
for (i = 1; i < block_length + 1; i++) {
|
|
|
|
const char *c = o->emitted_symbols->buf[n - i].line;
|
|
|
|
for (; *c; c++) {
|
|
|
|
if (!isalnum(*c))
|
|
|
|
continue;
|
|
|
|
alnum_count++;
|
|
|
|
if (alnum_count >= COLOR_MOVED_MIN_ALNUM_COUNT)
|
2018-11-23 19:16:55 +08:00
|
|
|
return 1;
|
2017-08-16 09:27:39 +08:00
|
|
|
}
|
|
|
|
}
|
2017-08-16 09:27:38 +08:00
|
|
|
for (i = 1; i < block_length + 1; i++)
|
2021-12-09 18:29:56 +08:00
|
|
|
o->emitted_symbols->buf[n - i].flags &= ~DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK;
|
2018-11-23 19:16:55 +08:00
|
|
|
return 0;
|
2017-08-16 09:27:38 +08:00
|
|
|
}
|
|
|
|
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
/* Find blocks of moved code, delegate actual coloring decision to helper */
|
|
|
|
static void mark_color_as_moved(struct diff_options *o,
|
2021-12-09 18:30:09 +08:00
|
|
|
struct moved_entry_list *entry_list)
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
{
|
2018-10-04 18:07:41 +08:00
|
|
|
struct moved_block *pmb = NULL; /* potentially moved blocks */
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
int pmb_nr = 0, pmb_alloc = 0;
|
2018-11-23 19:16:55 +08:00
|
|
|
int n, flipped_block = 0, block_length = 0;
|
2021-12-09 18:30:00 +08:00
|
|
|
enum diff_symbol moved_symbol = DIFF_SYMBOL_BINARY_DIFF_HEADER;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
for (n = 0; n < o->emitted_symbols->nr; n++) {
|
|
|
|
struct moved_entry *match = NULL;
|
|
|
|
struct emitted_diff_symbol *l = &o->emitted_symbols->buf[n];
|
|
|
|
|
|
|
|
switch (l->s) {
|
|
|
|
case DIFF_SYMBOL_PLUS:
|
2021-12-09 18:30:09 +08:00
|
|
|
match = entry_list[l->id].del;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MINUS:
|
2021-12-09 18:30:09 +08:00
|
|
|
match = entry_list[l->id].add;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
break;
|
|
|
|
default:
|
2018-11-23 19:16:55 +08:00
|
|
|
flipped_block = 0;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2021-12-09 18:30:00 +08:00
|
|
|
if (pmb_nr && (!match || l->s != moved_symbol)) {
|
2021-12-09 18:29:58 +08:00
|
|
|
if (!adjust_last_block(o, n, block_length) &&
|
|
|
|
block_length > 1) {
|
|
|
|
/*
|
|
|
|
* Rewind in case there is another match
|
|
|
|
* starting at the second line of the block
|
|
|
|
*/
|
|
|
|
match = NULL;
|
|
|
|
n -= block_length;
|
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
pmb_nr = 0;
|
|
|
|
block_length = 0;
|
2018-11-23 19:16:55 +08:00
|
|
|
flipped_block = 0;
|
2021-12-09 18:30:00 +08:00
|
|
|
}
|
|
|
|
if (!match) {
|
|
|
|
moved_symbol = DIFF_SYMBOL_BINARY_DIFF_HEADER;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-11-23 19:16:54 +08:00
|
|
|
if (o->color_moved == COLOR_MOVED_PLAIN) {
|
|
|
|
l->flags |= DIFF_SYMBOL_MOVED_LINE;
|
2017-07-01 04:53:08 +08:00
|
|
|
continue;
|
2018-11-23 19:16:54 +08:00
|
|
|
}
|
2017-07-01 04:53:08 +08:00
|
|
|
|
2021-12-09 18:30:05 +08:00
|
|
|
pmb_advance_or_null(o, l, pmb, &pmb_nr);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
|
|
|
if (pmb_nr == 0) {
|
2021-12-09 18:29:58 +08:00
|
|
|
int contiguous = adjust_last_block(o, n, block_length);
|
|
|
|
|
|
|
|
if (!contiguous && block_length > 1)
|
|
|
|
/*
|
|
|
|
* Rewind in case there is another match
|
|
|
|
* starting at the second line of the block
|
|
|
|
*/
|
|
|
|
n -= block_length;
|
|
|
|
else
|
2021-12-09 18:30:09 +08:00
|
|
|
fill_potential_moved_blocks(o, match, l,
|
2021-12-09 18:29:58 +08:00
|
|
|
&pmb, &pmb_alloc,
|
|
|
|
&pmb_nr);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:00 +08:00
|
|
|
if (contiguous && pmb_nr && moved_symbol == l->s)
|
2018-11-23 19:16:55 +08:00
|
|
|
flipped_block = (flipped_block + 1) % 2;
|
|
|
|
else
|
|
|
|
flipped_block = 0;
|
2017-08-16 09:27:39 +08:00
|
|
|
|
2021-12-09 18:30:00 +08:00
|
|
|
if (pmb_nr)
|
|
|
|
moved_symbol = l->s;
|
|
|
|
else
|
|
|
|
moved_symbol = DIFF_SYMBOL_BINARY_DIFF_HEADER;
|
|
|
|
|
2017-08-16 09:27:39 +08:00
|
|
|
block_length = 0;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2018-11-23 19:16:54 +08:00
|
|
|
if (pmb_nr) {
|
|
|
|
block_length++;
|
|
|
|
l->flags |= DIFF_SYMBOL_MOVED_LINE;
|
|
|
|
if (flipped_block && o->color_moved != COLOR_MOVED_BLOCKS)
|
|
|
|
l->flags |= DIFF_SYMBOL_MOVED_LINE_ALT;
|
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
2017-08-16 09:27:38 +08:00
|
|
|
adjust_last_block(o, n, block_length);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
|
|
|
free(pmb);
|
|
|
|
}
|
2017-06-30 08:07:06 +08:00
|
|
|
|
2017-07-01 04:53:09 +08:00
|
|
|
static void dim_moved_lines(struct diff_options *o)
|
|
|
|
{
|
|
|
|
int n;
|
|
|
|
for (n = 0; n < o->emitted_symbols->nr; n++) {
|
|
|
|
struct emitted_diff_symbol *prev = (n != 0) ?
|
|
|
|
&o->emitted_symbols->buf[n - 1] : NULL;
|
|
|
|
struct emitted_diff_symbol *l = &o->emitted_symbols->buf[n];
|
|
|
|
struct emitted_diff_symbol *next =
|
|
|
|
(n < o->emitted_symbols->nr - 1) ?
|
|
|
|
&o->emitted_symbols->buf[n + 1] : NULL;
|
|
|
|
|
|
|
|
/* Not a plus or minus line? */
|
|
|
|
if (l->s != DIFF_SYMBOL_PLUS && l->s != DIFF_SYMBOL_MINUS)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Not a moved line? */
|
|
|
|
if (!(l->flags & DIFF_SYMBOL_MOVED_LINE))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If prev or next are not a plus or minus line,
|
|
|
|
* pretend they don't exist
|
|
|
|
*/
|
|
|
|
if (prev && prev->s != DIFF_SYMBOL_PLUS &&
|
|
|
|
prev->s != DIFF_SYMBOL_MINUS)
|
|
|
|
prev = NULL;
|
|
|
|
if (next && next->s != DIFF_SYMBOL_PLUS &&
|
|
|
|
next->s != DIFF_SYMBOL_MINUS)
|
|
|
|
next = NULL;
|
|
|
|
|
|
|
|
/* Inside a block? */
|
|
|
|
if ((prev &&
|
|
|
|
(prev->flags & DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK) ==
|
|
|
|
(l->flags & DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK)) &&
|
|
|
|
(next &&
|
|
|
|
(next->flags & DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK) ==
|
|
|
|
(l->flags & DIFF_SYMBOL_MOVED_LINE_ZEBRA_MASK))) {
|
|
|
|
l->flags |= DIFF_SYMBOL_MOVED_LINE_UNINTERESTING;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if we are at an interesting bound: */
|
|
|
|
if (prev && (prev->flags & DIFF_SYMBOL_MOVED_LINE) &&
|
|
|
|
(prev->flags & DIFF_SYMBOL_MOVED_LINE_ALT) !=
|
|
|
|
(l->flags & DIFF_SYMBOL_MOVED_LINE_ALT))
|
|
|
|
continue;
|
|
|
|
if (next && (next->flags & DIFF_SYMBOL_MOVED_LINE) &&
|
|
|
|
(next->flags & DIFF_SYMBOL_MOVED_LINE_ALT) !=
|
|
|
|
(l->flags & DIFF_SYMBOL_MOVED_LINE_ALT))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The boundary to prev and next are not interesting,
|
|
|
|
* so this line is not interesting as a whole
|
|
|
|
*/
|
|
|
|
l->flags |= DIFF_SYMBOL_MOVED_LINE_UNINTERESTING;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-30 08:06:53 +08:00
|
|
|
static void emit_line_ws_markup(struct diff_options *o,
|
2018-08-14 09:41:18 +08:00
|
|
|
const char *set_sign, const char *set,
|
|
|
|
const char *reset,
|
2018-10-11 07:24:59 +08:00
|
|
|
int sign_index, const char *line, int len,
|
2017-06-30 08:06:53 +08:00
|
|
|
unsigned ws_rule, int blank_at_eof)
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
{
|
2015-05-27 01:11:28 +08:00
|
|
|
const char *ws = NULL;
|
2018-10-11 07:24:59 +08:00
|
|
|
int sign = o->output_indicators[sign_index];
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
|
2017-06-30 08:06:53 +08:00
|
|
|
if (o->ws_error_highlight & ws_rule) {
|
|
|
|
ws = diff_get_color_opt(o, DIFF_WHITESPACE);
|
2015-05-27 01:11:28 +08:00
|
|
|
if (!*ws)
|
|
|
|
ws = NULL;
|
|
|
|
}
|
|
|
|
|
2018-08-13 19:33:20 +08:00
|
|
|
if (!ws && !set_sign)
|
2018-08-14 09:41:19 +08:00
|
|
|
emit_line_0(o, set, NULL, 0, reset, sign, line, len);
|
2018-08-13 19:33:20 +08:00
|
|
|
else if (!ws) {
|
2018-08-14 09:41:20 +08:00
|
|
|
emit_line_0(o, set_sign, set, !!set_sign, reset, sign, line, len);
|
2018-08-13 19:33:20 +08:00
|
|
|
} else if (blank_at_eof)
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
/* Blank line at EOF - paint '+' as well */
|
2018-08-14 09:41:19 +08:00
|
|
|
emit_line_0(o, ws, NULL, 0, reset, sign, line, len);
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
else {
|
|
|
|
/* Emit just the prefix, then the rest. */
|
2018-08-14 09:41:19 +08:00
|
|
|
emit_line_0(o, set_sign ? set_sign : set, NULL, !!set_sign, reset,
|
2018-08-13 19:33:20 +08:00
|
|
|
sign, "", 0);
|
2017-06-30 08:06:53 +08:00
|
|
|
ws_check_emit(line, len, ws_rule,
|
|
|
|
o->file, set, reset, ws);
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:06 +08:00
|
|
|
static void emit_diff_symbol_from_struct(struct diff_options *o,
|
|
|
|
struct emitted_diff_symbol *eds)
|
2017-06-30 08:06:49 +08:00
|
|
|
{
|
2017-06-30 08:06:52 +08:00
|
|
|
static const char *nneof = " No newline at end of file\n";
|
2018-08-13 19:33:20 +08:00
|
|
|
const char *context, *reset, *set, *set_sign, *meta, *fraginfo;
|
2017-06-30 08:07:02 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
enum diff_symbol s = eds->s;
|
|
|
|
const char *line = eds->line;
|
|
|
|
int len = eds->len;
|
|
|
|
unsigned flags = eds->flags;
|
|
|
|
|
2017-06-30 08:06:49 +08:00
|
|
|
switch (s) {
|
2017-06-30 08:06:52 +08:00
|
|
|
case DIFF_SYMBOL_NO_LF_EOF:
|
|
|
|
context = diff_get_color_opt(o, DIFF_CONTEXT);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
putc('\n', o->file);
|
2018-08-14 09:41:19 +08:00
|
|
|
emit_line_0(o, context, NULL, 0, reset, '\\',
|
2017-06-30 08:06:52 +08:00
|
|
|
nneof, strlen(nneof));
|
|
|
|
break;
|
2017-06-30 08:07:00 +08:00
|
|
|
case DIFF_SYMBOL_SUBMODULE_HEADER:
|
|
|
|
case DIFF_SYMBOL_SUBMODULE_ERROR:
|
|
|
|
case DIFF_SYMBOL_SUBMODULE_PIPETHROUGH:
|
2017-06-30 08:07:02 +08:00
|
|
|
case DIFF_SYMBOL_STATS_SUMMARY_INSERTS_DELETES:
|
2017-06-30 08:07:05 +08:00
|
|
|
case DIFF_SYMBOL_SUMMARY:
|
2017-06-30 08:07:02 +08:00
|
|
|
case DIFF_SYMBOL_STATS_LINE:
|
2017-06-30 08:07:01 +08:00
|
|
|
case DIFF_SYMBOL_BINARY_DIFF_BODY:
|
2017-06-30 08:06:51 +08:00
|
|
|
case DIFF_SYMBOL_CONTEXT_FRAGINFO:
|
|
|
|
emit_line(o, "", "", line, len);
|
|
|
|
break;
|
2017-06-30 08:06:55 +08:00
|
|
|
case DIFF_SYMBOL_CONTEXT_INCOMPLETE:
|
2017-06-30 08:06:50 +08:00
|
|
|
case DIFF_SYMBOL_CONTEXT_MARKER:
|
|
|
|
context = diff_get_color_opt(o, DIFF_CONTEXT);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
emit_line(o, context, reset, line, len);
|
|
|
|
break;
|
2017-06-30 08:06:49 +08:00
|
|
|
case DIFF_SYMBOL_SEPARATOR:
|
|
|
|
fprintf(o->file, "%s%c",
|
|
|
|
diff_line_prefix(o),
|
|
|
|
o->line_termination);
|
|
|
|
break;
|
2017-06-30 08:06:53 +08:00
|
|
|
case DIFF_SYMBOL_CONTEXT:
|
|
|
|
set = diff_get_color_opt(o, DIFF_CONTEXT);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
2018-08-13 19:33:20 +08:00
|
|
|
set_sign = NULL;
|
|
|
|
if (o->flags.dual_color_diffed_diffs) {
|
|
|
|
char c = !len ? 0 : line[0];
|
|
|
|
|
|
|
|
if (c == '+')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW);
|
|
|
|
else if (c == '@')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FRAGINFO);
|
|
|
|
else if (c == '-')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD);
|
|
|
|
}
|
2018-08-18 04:43:52 +08:00
|
|
|
emit_line_ws_markup(o, set_sign, set, reset,
|
2018-10-11 07:24:59 +08:00
|
|
|
OUTPUT_INDICATOR_CONTEXT, line, len,
|
2017-06-30 08:06:53 +08:00
|
|
|
flags & (DIFF_SYMBOL_CONTENT_WS_MASK), 0);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_PLUS:
|
2017-07-01 04:53:09 +08:00
|
|
|
switch (flags & (DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING)) {
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_MOVED_ALT_DIM);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_MOVED_ALT);
|
2017-07-01 04:53:09 +08:00
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_MOVED_DIM);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_MOVED);
|
2017-07-01 04:53:09 +08:00
|
|
|
break;
|
|
|
|
default:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW);
|
2017-07-01 04:53:09 +08:00
|
|
|
}
|
2017-06-30 08:06:53 +08:00
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
2018-08-13 19:33:20 +08:00
|
|
|
if (!o->flags.dual_color_diffed_diffs)
|
|
|
|
set_sign = NULL;
|
|
|
|
else {
|
|
|
|
char c = !len ? 0 : line[0];
|
|
|
|
|
|
|
|
set_sign = set;
|
|
|
|
if (c == '-')
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_BOLD);
|
2018-08-13 19:33:20 +08:00
|
|
|
else if (c == '@')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FRAGINFO);
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
else if (c == '+')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_BOLD);
|
|
|
|
else
|
|
|
|
set = diff_get_color_opt(o, DIFF_CONTEXT_BOLD);
|
2018-08-13 19:33:24 +08:00
|
|
|
flags &= ~DIFF_SYMBOL_CONTENT_WS_MASK;
|
2018-08-13 19:33:20 +08:00
|
|
|
}
|
2018-08-18 04:43:52 +08:00
|
|
|
emit_line_ws_markup(o, set_sign, set, reset,
|
2018-10-11 07:24:59 +08:00
|
|
|
OUTPUT_INDICATOR_NEW, line, len,
|
2017-06-30 08:06:53 +08:00
|
|
|
flags & DIFF_SYMBOL_CONTENT_WS_MASK,
|
|
|
|
flags & DIFF_SYMBOL_CONTENT_BLANK_LINE_EOF);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MINUS:
|
2017-07-01 04:53:09 +08:00
|
|
|
switch (flags & (DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING)) {
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_MOVED_ALT_DIM);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_ALT:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_MOVED_ALT);
|
2017-07-01 04:53:09 +08:00
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE |
|
|
|
|
DIFF_SYMBOL_MOVED_LINE_UNINTERESTING:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_MOVED_DIM);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_MOVED_LINE:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_MOVED);
|
2017-07-01 04:53:09 +08:00
|
|
|
break;
|
|
|
|
default:
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD);
|
2017-07-01 04:53:09 +08:00
|
|
|
}
|
2017-06-30 08:06:53 +08:00
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
2018-08-13 19:33:20 +08:00
|
|
|
if (!o->flags.dual_color_diffed_diffs)
|
|
|
|
set_sign = NULL;
|
|
|
|
else {
|
|
|
|
char c = !len ? 0 : line[0];
|
|
|
|
|
|
|
|
set_sign = set;
|
|
|
|
if (c == '+')
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW_DIM);
|
2018-08-13 19:33:20 +08:00
|
|
|
else if (c == '@')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FRAGINFO);
|
range-diff: use dim/bold cues to improve dual color mode
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff does something
different than the old diff.
To make things easier to process for normal developers, we introduced
the dual color mode which colors the lines according to the commit diff,
i.e. lines that are added by a commit (whether old, new, or both) are
colored in green. In non-dual color mode, the lines would be colored
according to the outer diff: if the old commit added a line, it would be
colored red (because that line addition is only present in the first
commit range that was specified on the command-line, i.e. the "old"
commit, but not in the second commit range, i.e. the "new" commit).
However, this dual color mode is still not making things clear enough,
as we are looking at two levels of diffs, and we still only pick a color
according to *one* of them (the outer diff marker is colored
differently, of course, but in particular with deep indentation, it is
easy to lose track of that outer diff marker's background color).
Therefore, let's add another dimension to the mix. Still use
green/red/normal according to the commit diffs, but now also dim the
lines that were only in the old commit, and use bold face for the lines
that are only in the new commit.
That way, it is much easier not to lose track of, say, when we are
looking at a line that was added in the previous iteration of a patch
series but the new iteration adds a slightly different version: the
obsolete change will be dimmed, the current version of the patch will be
bold.
At least this developer has a much easier time reading the range-diffs
that way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
else if (c == '-')
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD_DIM);
|
|
|
|
else
|
|
|
|
set = diff_get_color_opt(o, DIFF_CONTEXT_DIM);
|
2018-08-13 19:33:20 +08:00
|
|
|
}
|
2018-08-18 04:43:52 +08:00
|
|
|
emit_line_ws_markup(o, set_sign, set, reset,
|
2018-10-11 07:24:59 +08:00
|
|
|
OUTPUT_INDICATOR_OLD, line, len,
|
2017-06-30 08:06:53 +08:00
|
|
|
flags & DIFF_SYMBOL_CONTENT_WS_MASK, 0);
|
|
|
|
break;
|
2017-06-30 08:06:54 +08:00
|
|
|
case DIFF_SYMBOL_WORDS_PORCELAIN:
|
|
|
|
context = diff_get_color_opt(o, DIFF_CONTEXT);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
emit_line(o, context, reset, line, len);
|
|
|
|
fputs("~\n", o->file);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_WORDS:
|
|
|
|
context = diff_get_color_opt(o, DIFF_CONTEXT);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
/*
|
|
|
|
* Skip the prefix character, if any. With
|
|
|
|
* diff_suppress_blank_empty, there may be
|
|
|
|
* none.
|
|
|
|
*/
|
|
|
|
if (line[0] != '\n') {
|
|
|
|
line++;
|
|
|
|
len--;
|
|
|
|
}
|
|
|
|
emit_line(o, context, reset, line, len);
|
|
|
|
break;
|
2017-06-30 08:06:56 +08:00
|
|
|
case DIFF_SYMBOL_FILEPAIR_PLUS:
|
|
|
|
meta = diff_get_color_opt(o, DIFF_METAINFO);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
fprintf(o->file, "%s%s+++ %s%s%s\n", diff_line_prefix(o), meta,
|
|
|
|
line, reset,
|
|
|
|
strchr(line, ' ') ? "\t" : "");
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_FILEPAIR_MINUS:
|
|
|
|
meta = diff_get_color_opt(o, DIFF_METAINFO);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
fprintf(o->file, "%s%s--- %s%s%s\n", diff_line_prefix(o), meta,
|
|
|
|
line, reset,
|
|
|
|
strchr(line, ' ') ? "\t" : "");
|
|
|
|
break;
|
2017-06-30 08:06:58 +08:00
|
|
|
case DIFF_SYMBOL_BINARY_FILES:
|
2017-06-30 08:06:57 +08:00
|
|
|
case DIFF_SYMBOL_HEADER:
|
|
|
|
fprintf(o->file, "%s", line);
|
|
|
|
break;
|
2017-06-30 08:07:01 +08:00
|
|
|
case DIFF_SYMBOL_BINARY_DIFF_HEADER:
|
|
|
|
fprintf(o->file, "%sGIT binary patch\n", diff_line_prefix(o));
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_BINARY_DIFF_HEADER_DELTA:
|
|
|
|
fprintf(o->file, "%sdelta %s\n", diff_line_prefix(o), line);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_BINARY_DIFF_HEADER_LITERAL:
|
|
|
|
fprintf(o->file, "%sliteral %s\n", diff_line_prefix(o), line);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_BINARY_DIFF_FOOTER:
|
|
|
|
fputs(diff_line_prefix(o), o->file);
|
|
|
|
fputc('\n', o->file);
|
|
|
|
break;
|
2017-06-30 08:06:59 +08:00
|
|
|
case DIFF_SYMBOL_REWRITE_DIFF:
|
|
|
|
fraginfo = diff_get_color(o->use_color, DIFF_FRAGINFO);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
emit_line(o, fraginfo, reset, line, len);
|
|
|
|
break;
|
2017-06-30 08:07:00 +08:00
|
|
|
case DIFF_SYMBOL_SUBMODULE_ADD:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_NEW);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
emit_line(o, set, reset, line, len);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_SUBMODULE_DEL:
|
|
|
|
set = diff_get_color_opt(o, DIFF_FILE_OLD);
|
|
|
|
reset = diff_get_color_opt(o, DIFF_RESET);
|
|
|
|
emit_line(o, set, reset, line, len);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_SUBMODULE_UNTRACKED:
|
|
|
|
fprintf(o->file, "%sSubmodule %s contains untracked content\n",
|
|
|
|
diff_line_prefix(o), line);
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_SUBMODULE_MODIFIED:
|
|
|
|
fprintf(o->file, "%sSubmodule %s contains modified content\n",
|
|
|
|
diff_line_prefix(o), line);
|
|
|
|
break;
|
2017-06-30 08:07:02 +08:00
|
|
|
case DIFF_SYMBOL_STATS_SUMMARY_NO_FILES:
|
|
|
|
emit_line(o, "", "", " 0 files changed\n",
|
|
|
|
strlen(" 0 files changed\n"));
|
|
|
|
break;
|
|
|
|
case DIFF_SYMBOL_STATS_SUMMARY_ABBREV:
|
|
|
|
emit_line(o, "", "", " ...\n", strlen(" ...\n"));
|
|
|
|
break;
|
2017-06-30 08:07:03 +08:00
|
|
|
case DIFF_SYMBOL_WORD_DIFF:
|
|
|
|
fprintf(o->file, "%.*s", len, line);
|
|
|
|
break;
|
2017-06-30 08:07:04 +08:00
|
|
|
case DIFF_SYMBOL_STAT_SEP:
|
|
|
|
fputs(o->stat_sep, o->file);
|
|
|
|
break;
|
2017-06-30 08:06:49 +08:00
|
|
|
default:
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("unknown diff symbol");
|
2017-06-30 08:06:49 +08:00
|
|
|
}
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_release(&sb);
|
2017-06-30 08:06:49 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:06 +08:00
|
|
|
static void emit_diff_symbol(struct diff_options *o, enum diff_symbol s,
|
|
|
|
const char *line, int len, unsigned flags)
|
|
|
|
{
|
2021-12-09 18:30:08 +08:00
|
|
|
struct emitted_diff_symbol e = {
|
|
|
|
.line = line, .len = len, .flags = flags, .s = s
|
|
|
|
};
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
if (o->emitted_symbols)
|
|
|
|
append_emitted_diff_symbol(o, &e);
|
|
|
|
else
|
|
|
|
emit_diff_symbol_from_struct(o, &e);
|
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:00 +08:00
|
|
|
void diff_emit_submodule_del(struct diff_options *o, const char *line)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_DEL, line, strlen(line), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_add(struct diff_options *o, const char *line)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_ADD, line, strlen(line), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_untracked(struct diff_options *o, const char *path)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_UNTRACKED,
|
|
|
|
path, strlen(path), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_modified(struct diff_options *o, const char *path)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_MODIFIED,
|
|
|
|
path, strlen(path), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_header(struct diff_options *o, const char *header)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_HEADER,
|
|
|
|
header, strlen(header), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_error(struct diff_options *o, const char *err)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_ERROR, err, strlen(err), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_emit_submodule_pipethrough(struct diff_options *o,
|
|
|
|
const char *line, int len)
|
|
|
|
{
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_SUBMODULE_PIPETHROUGH, line, len, 0);
|
|
|
|
}
|
|
|
|
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
static int new_blank_line_at_eof(struct emit_callback *ecbdata, const char *line, int len)
|
|
|
|
{
|
|
|
|
if (!((ecbdata->ws_rule & WS_BLANK_AT_EOF) &&
|
|
|
|
ecbdata->blank_at_eof_in_preimage &&
|
|
|
|
ecbdata->blank_at_eof_in_postimage &&
|
|
|
|
ecbdata->blank_at_eof_in_preimage <= ecbdata->lno_in_preimage &&
|
|
|
|
ecbdata->blank_at_eof_in_postimage <= ecbdata->lno_in_postimage))
|
|
|
|
return 0;
|
2009-09-15 09:44:01 +08:00
|
|
|
return ws_blank_line(line, len, ecbdata->ws_rule);
|
diff.c: shuffling code around
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-15 09:44:01 +08:00
|
|
|
}
|
|
|
|
|
2019-02-14 13:48:13 +08:00
|
|
|
static void emit_add_line(struct emit_callback *ecbdata,
|
2015-05-27 00:56:33 +08:00
|
|
|
const char *line, int len)
|
|
|
|
{
|
2017-06-30 08:06:53 +08:00
|
|
|
unsigned flags = WSEH_NEW | ecbdata->ws_rule;
|
|
|
|
if (new_blank_line_at_eof(ecbdata, line, len))
|
|
|
|
flags |= DIFF_SYMBOL_CONTENT_BLANK_LINE_EOF;
|
|
|
|
|
|
|
|
emit_diff_symbol(ecbdata->opt, DIFF_SYMBOL_PLUS, line, len, flags);
|
2015-05-27 01:11:28 +08:00
|
|
|
}
|
2015-05-27 00:56:33 +08:00
|
|
|
|
2019-02-14 13:48:13 +08:00
|
|
|
static void emit_del_line(struct emit_callback *ecbdata,
|
2015-05-27 01:11:28 +08:00
|
|
|
const char *line, int len)
|
|
|
|
{
|
2017-06-30 08:06:53 +08:00
|
|
|
unsigned flags = WSEH_OLD | ecbdata->ws_rule;
|
|
|
|
emit_diff_symbol(ecbdata->opt, DIFF_SYMBOL_MINUS, line, len, flags);
|
2015-05-27 00:56:33 +08:00
|
|
|
}
|
|
|
|
|
2019-02-14 13:48:13 +08:00
|
|
|
static void emit_context_line(struct emit_callback *ecbdata,
|
2015-05-27 00:56:33 +08:00
|
|
|
const char *line, int len)
|
|
|
|
{
|
2017-06-30 08:06:53 +08:00
|
|
|
unsigned flags = WSEH_CONTEXT | ecbdata->ws_rule;
|
|
|
|
emit_diff_symbol(ecbdata->opt, DIFF_SYMBOL_CONTEXT, line, len, flags);
|
2015-05-27 00:56:33 +08:00
|
|
|
}
|
|
|
|
|
2009-11-27 14:55:18 +08:00
|
|
|
static void emit_hunk_header(struct emit_callback *ecbdata,
|
|
|
|
const char *line, int len)
|
|
|
|
{
|
2015-05-28 04:48:46 +08:00
|
|
|
const char *context = diff_get_color(ecbdata->color_diff, DIFF_CONTEXT);
|
2009-11-27 14:55:18 +08:00
|
|
|
const char *frag = diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO);
|
|
|
|
const char *func = diff_get_color(ecbdata->color_diff, DIFF_FUNCINFO);
|
|
|
|
const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);
|
2018-08-13 19:33:20 +08:00
|
|
|
const char *reverse = ecbdata->color_diff ? GIT_COLOR_REVERSE : "";
|
2009-11-27 14:55:18 +08:00
|
|
|
static const char atat[2] = { '@', '@' };
|
|
|
|
const char *cp, *ep;
|
2010-05-29 23:32:05 +08:00
|
|
|
struct strbuf msgbuf = STRBUF_INIT;
|
|
|
|
int org_len = len;
|
|
|
|
int i = 1;
|
2009-11-27 14:55:18 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* As a hunk header must begin with "@@ -<old>, +<new> @@",
|
|
|
|
* it always is at least 10 bytes long.
|
|
|
|
*/
|
|
|
|
if (len < 10 ||
|
|
|
|
memcmp(line, atat, 2) ||
|
|
|
|
!(ep = memmem(line + 2, len - 2, atat, 2))) {
|
2017-06-30 08:06:50 +08:00
|
|
|
emit_diff_symbol(ecbdata->opt,
|
2017-06-30 08:06:53 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT_MARKER, line, len, 0);
|
2009-11-27 14:55:18 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
ep += 2; /* skip over @@ */
|
|
|
|
|
|
|
|
/* The hunk header in fraginfo color */
|
2018-08-13 19:33:20 +08:00
|
|
|
if (ecbdata->opt->flags.dual_color_diffed_diffs)
|
|
|
|
strbuf_addstr(&msgbuf, reverse);
|
2014-07-17 07:38:18 +08:00
|
|
|
strbuf_addstr(&msgbuf, frag);
|
2019-07-12 00:08:48 +08:00
|
|
|
if (ecbdata->opt->flags.suppress_hunk_header_line_count)
|
|
|
|
strbuf_add(&msgbuf, atat, sizeof(atat));
|
|
|
|
else
|
|
|
|
strbuf_add(&msgbuf, line, ep - line);
|
2014-07-17 07:38:18 +08:00
|
|
|
strbuf_addstr(&msgbuf, reset);
|
2010-05-29 23:32:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* trailing "\r\n"
|
|
|
|
*/
|
|
|
|
for ( ; i < 3; i++)
|
|
|
|
if (line[len - i] == '\r' || line[len - i] == '\n')
|
|
|
|
len--;
|
2009-11-27 14:55:18 +08:00
|
|
|
|
|
|
|
/* blank before the func header */
|
|
|
|
for (cp = ep; ep - line < len; ep++)
|
|
|
|
if (*ep != ' ' && *ep != '\t')
|
|
|
|
break;
|
2010-05-29 23:32:05 +08:00
|
|
|
if (ep != cp) {
|
2015-05-28 04:48:46 +08:00
|
|
|
strbuf_addstr(&msgbuf, context);
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_add(&msgbuf, cp, ep - cp);
|
2014-07-17 07:38:18 +08:00
|
|
|
strbuf_addstr(&msgbuf, reset);
|
2010-05-29 23:32:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ep < line + len) {
|
2014-07-17 07:38:18 +08:00
|
|
|
strbuf_addstr(&msgbuf, func);
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_add(&msgbuf, ep, line + len - ep);
|
2014-07-17 07:38:18 +08:00
|
|
|
strbuf_addstr(&msgbuf, reset);
|
2010-05-29 23:32:05 +08:00
|
|
|
}
|
2009-11-27 14:55:18 +08:00
|
|
|
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_add(&msgbuf, line + len, org_len - len);
|
2017-06-30 08:06:47 +08:00
|
|
|
strbuf_complete_line(&msgbuf);
|
2017-06-30 08:06:51 +08:00
|
|
|
emit_diff_symbol(ecbdata->opt,
|
2017-06-30 08:06:53 +08:00
|
|
|
DIFF_SYMBOL_CONTEXT_FRAGINFO, msgbuf.buf, msgbuf.len, 0);
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_release(&msgbuf);
|
2009-11-27 14:55:18 +08:00
|
|
|
}
|
|
|
|
|
2018-12-09 18:25:21 +08:00
|
|
|
static struct diff_tempfile *claim_diff_tempfile(void)
|
|
|
|
{
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
int i;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_temp); i++)
|
|
|
|
if (!diff_temp[i].name)
|
|
|
|
return diff_temp + i;
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("diff is failing to clean up its tempfiles");
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void remove_tempfile(void)
|
|
|
|
{
|
|
|
|
int i;
|
2009-02-12 21:36:14 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_temp); i++) {
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
if (is_tempfile_active(diff_temp[i].tempfile))
|
2015-08-13 01:12:01 +08:00
|
|
|
delete_tempfile(&diff_temp[i].tempfile);
|
2009-02-12 21:36:14 +08:00
|
|
|
diff_temp[i].name = NULL;
|
|
|
|
}
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:06:59 +08:00
|
|
|
static void add_line_count(struct strbuf *out, int count)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
switch (count) {
|
|
|
|
case 0:
|
2017-06-30 08:06:59 +08:00
|
|
|
strbuf_addstr(out, "0,0");
|
2006-04-22 14:57:45 +08:00
|
|
|
break;
|
|
|
|
case 1:
|
2017-06-30 08:06:59 +08:00
|
|
|
strbuf_addstr(out, "1");
|
2006-04-22 14:57:45 +08:00
|
|
|
break;
|
|
|
|
default:
|
2017-06-30 08:06:59 +08:00
|
|
|
strbuf_addf(out, "1,%d", count);
|
2006-04-22 14:57:45 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-09-15 09:44:01 +08:00
|
|
|
static void emit_rewrite_lines(struct emit_callback *ecb,
|
|
|
|
int prefix, const char *data, int size)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2009-09-15 09:44:01 +08:00
|
|
|
const char *endp = NULL;
|
|
|
|
|
|
|
|
while (0 < size) {
|
|
|
|
int len;
|
|
|
|
|
|
|
|
endp = memchr(data, '\n', size);
|
|
|
|
len = endp ? (endp - data + 1) : size;
|
|
|
|
if (prefix != '+') {
|
|
|
|
ecb->lno_in_preimage++;
|
2019-02-14 13:48:13 +08:00
|
|
|
emit_del_line(ecb, data, len);
|
2009-09-15 09:44:01 +08:00
|
|
|
} else {
|
|
|
|
ecb->lno_in_postimage++;
|
2019-02-14 13:48:13 +08:00
|
|
|
emit_add_line(ecb, data, len);
|
2007-02-20 22:08:46 +08:00
|
|
|
}
|
2009-09-15 09:44:01 +08:00
|
|
|
size -= len;
|
|
|
|
data += len;
|
|
|
|
}
|
2017-06-30 08:06:52 +08:00
|
|
|
if (!endp)
|
2017-06-30 08:06:53 +08:00
|
|
|
emit_diff_symbol(ecb->opt, DIFF_SYMBOL_NO_LF_EOF, NULL, 0, 0);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void emit_rewrite_diff(const char *name_a,
|
|
|
|
const char *name_b,
|
|
|
|
struct diff_filespec *one,
|
2007-02-20 22:08:46 +08:00
|
|
|
struct diff_filespec *two,
|
2010-04-02 08:12:15 +08:00
|
|
|
struct userdiff_driver *textconv_one,
|
|
|
|
struct userdiff_driver *textconv_two,
|
2007-12-19 03:32:14 +08:00
|
|
|
struct diff_options *o)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
int lc_a, lc_b;
|
2007-12-27 09:13:36 +08:00
|
|
|
static struct strbuf a_name = STRBUF_INIT, b_name = STRBUF_INIT;
|
2008-08-19 11:08:09 +08:00
|
|
|
const char *a_prefix, *b_prefix;
|
2010-04-02 08:09:26 +08:00
|
|
|
char *data_one, *data_two;
|
2008-12-09 16:13:21 +08:00
|
|
|
size_t size_one, size_two;
|
2009-09-15 09:44:01 +08:00
|
|
|
struct emit_callback ecbdata;
|
2017-06-30 08:06:59 +08:00
|
|
|
struct strbuf out = STRBUF_INIT;
|
2008-08-19 11:08:09 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (diff_mnemonic_prefix && o->flags.reverse_diff) {
|
2008-08-19 11:08:09 +08:00
|
|
|
a_prefix = o->b_prefix;
|
|
|
|
b_prefix = o->a_prefix;
|
|
|
|
} else {
|
|
|
|
a_prefix = o->a_prefix;
|
|
|
|
b_prefix = o->b_prefix;
|
|
|
|
}
|
2006-09-23 07:17:58 +08:00
|
|
|
|
2007-02-24 17:42:06 +08:00
|
|
|
name_a += (*name_a == '/');
|
|
|
|
name_b += (*name_b == '/');
|
2006-09-23 07:17:58 +08:00
|
|
|
|
2007-12-27 09:13:36 +08:00
|
|
|
strbuf_reset(&a_name);
|
|
|
|
strbuf_reset(&b_name);
|
2008-08-19 11:08:09 +08:00
|
|
|
quote_two_c_style(&a_name, a_prefix, name_a, 0);
|
|
|
|
quote_two_c_style(&b_name, b_prefix, name_b, 0);
|
2007-12-27 09:13:36 +08:00
|
|
|
|
2018-09-21 23:57:22 +08:00
|
|
|
size_one = fill_textconv(o->repo, textconv_one, one, &data_one);
|
|
|
|
size_two = fill_textconv(o->repo, textconv_two, two, &data_two);
|
2008-12-09 16:13:21 +08:00
|
|
|
|
2009-09-16 02:21:10 +08:00
|
|
|
memset(&ecbdata, 0, sizeof(ecbdata));
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 13:04:23 +08:00
|
|
|
ecbdata.color_diff = want_color(o->use_color);
|
2018-09-21 23:57:37 +08:00
|
|
|
ecbdata.ws_rule = whitespace_rule(o->repo->index, name_b);
|
2010-05-26 15:08:02 +08:00
|
|
|
ecbdata.opt = o;
|
2009-09-16 02:21:10 +08:00
|
|
|
if (ecbdata.ws_rule & WS_BLANK_AT_EOF) {
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
mf1.ptr = (char *)data_one;
|
|
|
|
mf2.ptr = (char *)data_two;
|
|
|
|
mf1.size = size_one;
|
|
|
|
mf2.size = size_two;
|
|
|
|
check_blank_at_eof(&mf1, &mf2, &ecbdata);
|
|
|
|
}
|
|
|
|
ecbdata.lno_in_preimage = 1;
|
|
|
|
ecbdata.lno_in_postimage = 1;
|
|
|
|
|
2008-12-09 16:13:21 +08:00
|
|
|
lc_a = count_lines(data_one, size_one);
|
|
|
|
lc_b = count_lines(data_two, size_two);
|
2017-06-30 08:06:56 +08:00
|
|
|
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_FILEPAIR_MINUS,
|
|
|
|
a_name.buf, a_name.len, 0);
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_FILEPAIR_PLUS,
|
|
|
|
b_name.buf, b_name.len, 0);
|
|
|
|
|
2017-06-30 08:06:59 +08:00
|
|
|
strbuf_addstr(&out, "@@ -");
|
2011-03-01 08:11:55 +08:00
|
|
|
if (!o->irreversible_delete)
|
2017-06-30 08:06:59 +08:00
|
|
|
add_line_count(&out, lc_a);
|
2011-03-01 08:11:55 +08:00
|
|
|
else
|
2017-06-30 08:06:59 +08:00
|
|
|
strbuf_addstr(&out, "?,?");
|
|
|
|
strbuf_addstr(&out, " +");
|
|
|
|
add_line_count(&out, lc_b);
|
|
|
|
strbuf_addstr(&out, " @@\n");
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_REWRITE_DIFF, out.buf, out.len, 0);
|
|
|
|
strbuf_release(&out);
|
|
|
|
|
2011-03-01 08:11:55 +08:00
|
|
|
if (lc_a && !o->irreversible_delete)
|
2009-09-16 02:21:10 +08:00
|
|
|
emit_rewrite_lines(&ecbdata, '-', data_one, size_one);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (lc_b)
|
2009-09-16 02:21:10 +08:00
|
|
|
emit_rewrite_lines(&ecbdata, '+', data_two, size_two);
|
2010-04-02 08:04:14 +08:00
|
|
|
if (textconv_one)
|
2010-04-09 14:30:49 +08:00
|
|
|
free((char *)data_one);
|
2010-04-02 08:04:14 +08:00
|
|
|
if (textconv_two)
|
2010-04-09 14:30:49 +08:00
|
|
|
free((char *)data_two);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-07-29 05:56:15 +08:00
|
|
|
struct diff_words_buffer {
|
|
|
|
mmfile_t text;
|
2017-09-22 00:49:38 +08:00
|
|
|
unsigned long alloc;
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
struct diff_words_orig {
|
|
|
|
const char *begin, *end;
|
|
|
|
} *orig;
|
|
|
|
int orig_nr, orig_alloc;
|
2006-07-29 05:56:15 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static void diff_words_append(char *line, unsigned long len,
|
|
|
|
struct diff_words_buffer *buffer)
|
|
|
|
{
|
2009-01-18 00:29:43 +08:00
|
|
|
ALLOC_GROW(buffer->text.ptr, buffer->text.size + len, buffer->alloc);
|
2006-07-29 05:56:15 +08:00
|
|
|
line++;
|
|
|
|
len--;
|
|
|
|
memcpy(buffer->text.ptr + buffer->text.size, line, len);
|
|
|
|
buffer->text.size += len;
|
2009-01-18 00:29:45 +08:00
|
|
|
buffer->text.ptr[buffer->text.size] = '\0';
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct diff_words_style_elem {
|
2010-04-14 23:59:06 +08:00
|
|
|
const char *prefix;
|
|
|
|
const char *suffix;
|
|
|
|
const char *color; /* NULL; filled in by the setup code if
|
|
|
|
* color is enabled */
|
|
|
|
};
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct diff_words_style {
|
2010-04-14 23:59:06 +08:00
|
|
|
enum diff_words_type type;
|
2018-02-15 02:59:39 +08:00
|
|
|
struct diff_words_style_elem new_word, old_word, ctx;
|
2010-04-14 23:59:06 +08:00
|
|
|
const char *newline;
|
|
|
|
};
|
|
|
|
|
Fix sparse warnings
Fix warnings from 'make check'.
- These files don't include 'builtin.h' causing sparse to complain that
cmd_* isn't declared:
builtin/clone.c:364, builtin/fetch-pack.c:797,
builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
builtin/merge-index.c:69, builtin/merge-recursive.c:22
builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
builtin/notes.c:822, builtin/pack-redundant.c:596,
builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
builtin/remote.c:1512, builtin/remote-ext.c:240,
builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
builtin/unpack-file.c:25, builtin/var.c:75
- These files have symbols which should be marked static since they're
only file scope:
submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48
- These files redeclare symbols to be different types:
builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
usage.c:49, usage.c:58, usage.c:63, usage.c:72
- These files use a literal integer 0 when they really should use a NULL
pointer:
daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362
While we're in the area, clean up some unused #includes in builtin files
(mostly exec_cmd.h).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22 15:51:05 +08:00
|
|
|
static struct diff_words_style diff_words_styles[] = {
|
2010-04-14 23:59:06 +08:00
|
|
|
{ DIFF_WORDS_PORCELAIN, {"+", "\n"}, {"-", "\n"}, {" ", "\n"}, "~\n" },
|
|
|
|
{ DIFF_WORDS_PLAIN, {"{+", "+}"}, {"[-", "-]"}, {"", ""}, "\n" },
|
|
|
|
{ DIFF_WORDS_COLOR, {"", ""}, {"", ""}, {"", ""}, "\n" }
|
|
|
|
};
|
|
|
|
|
2006-07-29 05:56:15 +08:00
|
|
|
struct diff_words_data {
|
|
|
|
struct diff_words_buffer minus, plus;
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
const char *current_plus;
|
2010-05-29 23:32:06 +08:00
|
|
|
int last_minus;
|
|
|
|
struct diff_options *opt;
|
2009-01-18 00:29:45 +08:00
|
|
|
regex_t *word_regex;
|
2010-04-14 23:59:06 +08:00
|
|
|
enum diff_words_type type;
|
|
|
|
struct diff_words_style *style;
|
2006-07-29 05:56:15 +08:00
|
|
|
};
|
|
|
|
|
2017-06-30 08:07:03 +08:00
|
|
|
static int fn_out_diff_words_write_helper(struct diff_options *o,
|
2010-04-14 23:59:06 +08:00
|
|
|
struct diff_words_style_elem *st_el,
|
|
|
|
const char *newline,
|
2017-06-30 08:07:03 +08:00
|
|
|
size_t count, const char *buf)
|
2010-04-14 23:59:06 +08:00
|
|
|
{
|
2010-05-29 23:32:06 +08:00
|
|
|
int print = 0;
|
2017-06-30 08:07:03 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2010-05-29 23:32:06 +08:00
|
|
|
|
2010-04-14 23:59:06 +08:00
|
|
|
while (count) {
|
|
|
|
char *p = memchr(buf, '\n', count);
|
2010-05-29 23:32:06 +08:00
|
|
|
if (print)
|
2017-06-30 08:07:03 +08:00
|
|
|
strbuf_addstr(&sb, diff_line_prefix(o));
|
|
|
|
|
2010-04-14 23:59:06 +08:00
|
|
|
if (p != buf) {
|
2017-06-30 08:07:03 +08:00
|
|
|
const char *reset = st_el->color && *st_el->color ?
|
|
|
|
GIT_COLOR_RESET : NULL;
|
|
|
|
if (st_el->color && *st_el->color)
|
|
|
|
strbuf_addstr(&sb, st_el->color);
|
|
|
|
strbuf_addstr(&sb, st_el->prefix);
|
|
|
|
strbuf_add(&sb, buf, p ? p - buf : count);
|
|
|
|
strbuf_addstr(&sb, st_el->suffix);
|
|
|
|
if (reset)
|
|
|
|
strbuf_addstr(&sb, reset);
|
2010-04-14 23:59:06 +08:00
|
|
|
}
|
|
|
|
if (!p)
|
2017-06-30 08:07:03 +08:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
strbuf_addstr(&sb, newline);
|
2010-04-14 23:59:06 +08:00
|
|
|
count -= p + 1 - buf;
|
|
|
|
buf = p + 1;
|
2010-05-29 23:32:06 +08:00
|
|
|
print = 1;
|
2017-06-30 08:07:03 +08:00
|
|
|
if (count) {
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_WORD_DIFF,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_reset(&sb);
|
|
|
|
}
|
2010-04-14 23:59:06 +08:00
|
|
|
}
|
2017-06-30 08:07:03 +08:00
|
|
|
|
|
|
|
out:
|
|
|
|
if (sb.len)
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_WORD_DIFF,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_release(&sb);
|
2010-04-14 23:59:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-05-29 23:32:06 +08:00
|
|
|
/*
|
|
|
|
* '--color-words' algorithm can be described as:
|
|
|
|
*
|
2017-04-30 23:48:27 +08:00
|
|
|
* 1. collect the minus/plus lines of a diff hunk, divided into
|
2010-05-29 23:32:06 +08:00
|
|
|
* minus-lines and plus-lines;
|
|
|
|
*
|
|
|
|
* 2. break both minus-lines and plus-lines into words and
|
|
|
|
* place them into two mmfile_t with one word for each line;
|
|
|
|
*
|
|
|
|
* 3. use xdiff to run diff on the two mmfile_t to get the words level diff;
|
|
|
|
*
|
|
|
|
* And for the common parts of the both file, we output the plus side text.
|
|
|
|
* diff_words->current_plus is used to trace the current position of the plus file
|
|
|
|
* which printed. diff_words->last_minus is used to trace the last minus word
|
|
|
|
* printed.
|
|
|
|
*
|
|
|
|
* For '--graph' to work with '--color-words', we need to output the graph prefix
|
|
|
|
* on each line of color words output. Generally, there are two conditions on
|
|
|
|
* which we should output the prefix.
|
|
|
|
*
|
|
|
|
* 1. diff_words->last_minus == 0 &&
|
|
|
|
* diff_words->current_plus == diff_words->plus.text.ptr
|
|
|
|
*
|
|
|
|
* that is: the plus text must start as a new line, and if there is no minus
|
|
|
|
* word printed, a graph prefix must be printed.
|
|
|
|
*
|
|
|
|
* 2. diff_words->current_plus > diff_words->plus.text.ptr &&
|
|
|
|
* *(diff_words->current_plus - 1) == '\n'
|
|
|
|
*
|
|
|
|
* that is: a graph prefix must be printed following a '\n'
|
|
|
|
*/
|
|
|
|
static int color_words_output_graph_prefix(struct diff_words_data *diff_words)
|
|
|
|
{
|
|
|
|
if ((diff_words->last_minus == 0 &&
|
|
|
|
diff_words->current_plus == diff_words->plus.text.ptr) ||
|
|
|
|
(diff_words->current_plus > diff_words->plus.text.ptr &&
|
|
|
|
*(diff_words->current_plus - 1) == '\n')) {
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-02 14:37:18 +08:00
|
|
|
static void fn_out_diff_words_aux(void *priv,
|
|
|
|
long minus_first, long minus_len,
|
|
|
|
long plus_first, long plus_len,
|
|
|
|
const char *func, long funclen)
|
2006-07-29 05:56:15 +08:00
|
|
|
{
|
|
|
|
struct diff_words_data *diff_words = priv;
|
2010-04-14 23:59:06 +08:00
|
|
|
struct diff_words_style *style = diff_words->style;
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
const char *minus_begin, *minus_end, *plus_begin, *plus_end;
|
2010-05-29 23:32:06 +08:00
|
|
|
struct diff_options *opt = diff_words->opt;
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
2010-05-29 23:32:06 +08:00
|
|
|
assert(opt);
|
2013-02-08 04:15:27 +08:00
|
|
|
line_prefix = diff_line_prefix(opt);
|
2010-05-29 23:32:06 +08:00
|
|
|
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
/* POSIX requires that first be decremented by one if len == 0... */
|
|
|
|
if (minus_len) {
|
|
|
|
minus_begin = diff_words->minus.orig[minus_first].begin;
|
|
|
|
minus_end =
|
|
|
|
diff_words->minus.orig[minus_first + minus_len - 1].end;
|
|
|
|
} else
|
|
|
|
minus_begin = minus_end =
|
|
|
|
diff_words->minus.orig[minus_first].end;
|
|
|
|
|
|
|
|
if (plus_len) {
|
|
|
|
plus_begin = diff_words->plus.orig[plus_first].begin;
|
|
|
|
plus_end = diff_words->plus.orig[plus_first + plus_len - 1].end;
|
|
|
|
} else
|
|
|
|
plus_begin = plus_end = diff_words->plus.orig[plus_first].end;
|
|
|
|
|
2010-05-29 23:32:06 +08:00
|
|
|
if (color_words_output_graph_prefix(diff_words)) {
|
|
|
|
fputs(line_prefix, diff_words->opt->file);
|
|
|
|
}
|
|
|
|
if (diff_words->current_plus != plus_begin) {
|
2017-06-30 08:07:03 +08:00
|
|
|
fn_out_diff_words_write_helper(diff_words->opt,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->ctx, style->newline,
|
|
|
|
plus_begin - diff_words->current_plus,
|
2017-06-30 08:07:03 +08:00
|
|
|
diff_words->current_plus);
|
2010-05-29 23:32:06 +08:00
|
|
|
}
|
|
|
|
if (minus_begin != minus_end) {
|
2017-06-30 08:07:03 +08:00
|
|
|
fn_out_diff_words_write_helper(diff_words->opt,
|
2018-02-15 02:59:39 +08:00
|
|
|
&style->old_word, style->newline,
|
2017-06-30 08:07:03 +08:00
|
|
|
minus_end - minus_begin, minus_begin);
|
2010-05-29 23:32:06 +08:00
|
|
|
}
|
|
|
|
if (plus_begin != plus_end) {
|
2017-06-30 08:07:03 +08:00
|
|
|
fn_out_diff_words_write_helper(diff_words->opt,
|
2018-02-15 02:59:39 +08:00
|
|
|
&style->new_word, style->newline,
|
2017-06-30 08:07:03 +08:00
|
|
|
plus_end - plus_begin, plus_begin);
|
2010-05-29 23:32:06 +08:00
|
|
|
}
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
|
|
|
|
diff_words->current_plus = plus_end;
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->last_minus = minus_first;
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
|
2009-01-18 00:29:45 +08:00
|
|
|
/* This function starts looking at *begin, and returns 0 iff a word was found. */
|
|
|
|
static int find_word_boundaries(mmfile_t *buffer, regex_t *word_regex,
|
|
|
|
int *begin, int *end)
|
|
|
|
{
|
2021-05-04 17:27:34 +08:00
|
|
|
while (word_regex && *begin < buffer->size) {
|
2009-01-18 00:29:45 +08:00
|
|
|
regmatch_t match[1];
|
2016-09-22 02:24:14 +08:00
|
|
|
if (!regexec_buf(word_regex, buffer->ptr + *begin,
|
|
|
|
buffer->size - *begin, 1, match, 0)) {
|
2009-01-18 00:29:45 +08:00
|
|
|
char *p = memchr(buffer->ptr + *begin + match[0].rm_so,
|
|
|
|
'\n', match[0].rm_eo - match[0].rm_so);
|
|
|
|
*end = p ? p - buffer->ptr : match[0].rm_eo + *begin;
|
|
|
|
*begin += match[0].rm_so;
|
2021-05-04 17:27:34 +08:00
|
|
|
if (*begin == *end)
|
|
|
|
(*begin)++;
|
|
|
|
else
|
|
|
|
return *begin > *end;
|
|
|
|
} else {
|
|
|
|
return -1;
|
2009-01-18 00:29:45 +08:00
|
|
|
}
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
|
2009-01-18 00:29:45 +08:00
|
|
|
/* find the next word */
|
|
|
|
while (*begin < buffer->size && isspace(buffer->ptr[*begin]))
|
|
|
|
(*begin)++;
|
|
|
|
if (*begin >= buffer->size)
|
|
|
|
return -1;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
2009-01-18 00:29:45 +08:00
|
|
|
/* find the end of the word */
|
|
|
|
*end = *begin + 1;
|
|
|
|
while (*end < buffer->size && !isspace(buffer->ptr[*end]))
|
|
|
|
(*end)++;
|
|
|
|
|
|
|
|
return 0;
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
|
2009-01-18 00:29:43 +08:00
|
|
|
/*
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
* This function splits the words in buffer->text, stores the list with
|
|
|
|
* newline separator into out, and saves the offsets of the original words
|
|
|
|
* in buffer->orig.
|
2009-01-18 00:29:43 +08:00
|
|
|
*/
|
2009-01-18 00:29:45 +08:00
|
|
|
static void diff_words_fill(struct diff_words_buffer *buffer, mmfile_t *out,
|
|
|
|
regex_t *word_regex)
|
2006-07-29 05:56:15 +08:00
|
|
|
{
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
int i, j;
|
2009-01-18 00:29:45 +08:00
|
|
|
long alloc = 0;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
out->size = 0;
|
2009-01-18 00:29:45 +08:00
|
|
|
out->ptr = NULL;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
/* fake an empty "0th" word */
|
|
|
|
ALLOC_GROW(buffer->orig, 1, buffer->orig_alloc);
|
|
|
|
buffer->orig[0].begin = buffer->orig[0].end = buffer->text.ptr;
|
|
|
|
buffer->orig_nr = 1;
|
|
|
|
|
|
|
|
for (i = 0; i < buffer->text.size; i++) {
|
2009-01-18 00:29:45 +08:00
|
|
|
if (find_word_boundaries(&buffer->text, word_regex, &i, &j))
|
|
|
|
return;
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
|
|
|
|
/* store original boundaries */
|
|
|
|
ALLOC_GROW(buffer->orig, buffer->orig_nr + 1,
|
|
|
|
buffer->orig_alloc);
|
|
|
|
buffer->orig[buffer->orig_nr].begin = buffer->text.ptr + i;
|
|
|
|
buffer->orig[buffer->orig_nr].end = buffer->text.ptr + j;
|
|
|
|
buffer->orig_nr++;
|
|
|
|
|
|
|
|
/* store one word */
|
2009-01-18 00:29:45 +08:00
|
|
|
ALLOC_GROW(out->ptr, out->size + j - i + 1, alloc);
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
memcpy(out->ptr + out->size, buffer->text.ptr + i, j - i);
|
|
|
|
out->ptr[out->size + j - i] = '\n';
|
|
|
|
out->size += j - i + 1;
|
|
|
|
|
|
|
|
i = j - 1;
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* this executes the word diff on the accumulated buffers */
|
|
|
|
static void diff_words_show(struct diff_words_data *diff_words)
|
|
|
|
{
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
mmfile_t minus, plus;
|
2010-04-14 23:59:06 +08:00
|
|
|
struct diff_words_style *style = diff_words->style;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
2010-05-29 23:32:06 +08:00
|
|
|
struct diff_options *opt = diff_words->opt;
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix;
|
2010-05-29 23:32:06 +08:00
|
|
|
|
|
|
|
assert(opt);
|
2013-02-08 04:15:27 +08:00
|
|
|
line_prefix = diff_line_prefix(opt);
|
2010-05-29 23:32:06 +08:00
|
|
|
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
/* special case: only removal */
|
|
|
|
if (!diff_words->plus.text.size) {
|
2017-06-30 08:07:03 +08:00
|
|
|
emit_diff_symbol(diff_words->opt, DIFF_SYMBOL_WORD_DIFF,
|
|
|
|
line_prefix, strlen(line_prefix), 0);
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt,
|
2018-02-15 02:59:39 +08:00
|
|
|
&style->old_word, style->newline,
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->minus.text.size,
|
2017-06-30 08:07:03 +08:00
|
|
|
diff_words->minus.text.ptr);
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
diff_words->minus.text.size = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
diff_words->current_plus = diff_words->plus.text.ptr;
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->last_minus = 0;
|
2006-07-29 05:56:15 +08:00
|
|
|
|
2008-10-25 21:30:37 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2009-01-18 00:29:45 +08:00
|
|
|
diff_words_fill(&diff_words->minus, &minus, diff_words->word_regex);
|
|
|
|
diff_words_fill(&diff_words->plus, &plus, diff_words->word_regex);
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = 0;
|
2009-01-18 00:29:45 +08:00
|
|
|
/* as only the hunk header will be parsed, we need a 0-context */
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
xecfg.ctxlen = 0;
|
2018-11-02 14:37:18 +08:00
|
|
|
if (xdi_diff_outf(&minus, &plus, fn_out_diff_words_aux, NULL,
|
2018-11-02 14:35:45 +08:00
|
|
|
diff_words, &xpp, &xecfg))
|
react to errors in xdi_diff
When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).
In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.
Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.
We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).
There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 07:12:23 +08:00
|
|
|
die("unable to generate word diff");
|
2006-07-29 05:56:15 +08:00
|
|
|
free(minus.ptr);
|
|
|
|
free(plus.ptr);
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
if (diff_words->current_plus != diff_words->plus.text.ptr +
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->plus.text.size) {
|
|
|
|
if (color_words_output_graph_prefix(diff_words))
|
2017-06-30 08:07:03 +08:00
|
|
|
emit_diff_symbol(diff_words->opt, DIFF_SYMBOL_WORD_DIFF,
|
|
|
|
line_prefix, strlen(line_prefix), 0);
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->ctx, style->newline,
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
diff_words->plus.text.ptr + diff_words->plus.text.size
|
2017-06-30 08:07:03 +08:00
|
|
|
- diff_words->current_plus, diff_words->current_plus);
|
2010-05-29 23:32:06 +08:00
|
|
|
}
|
2006-07-29 05:56:15 +08:00
|
|
|
diff_words->minus.text.size = diff_words->plus.text.size = 0;
|
|
|
|
}
|
|
|
|
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
/* In "color-words" mode, show word-diff of words accumulated in the buffer */
|
|
|
|
static void diff_words_flush(struct emit_callback *ecbdata)
|
|
|
|
{
|
2017-06-30 08:07:06 +08:00
|
|
|
struct diff_options *wo = ecbdata->diff_words->opt;
|
|
|
|
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
if (ecbdata->diff_words->minus.text.size ||
|
|
|
|
ecbdata->diff_words->plus.text.size)
|
|
|
|
diff_words_show(ecbdata->diff_words);
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
if (wo->emitted_symbols) {
|
|
|
|
struct diff_options *o = ecbdata->opt;
|
|
|
|
struct emitted_diff_symbols *wol = wo->emitted_symbols;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NEEDSWORK:
|
|
|
|
* Instead of appending each, concat all words to a line?
|
|
|
|
*/
|
|
|
|
for (i = 0; i < wol->nr; i++)
|
|
|
|
append_emitted_diff_symbol(o, &wol->buf[i]);
|
|
|
|
|
|
|
|
for (i = 0; i < wol->nr; i++)
|
|
|
|
free((void *)wol->buf[i].line);
|
|
|
|
|
|
|
|
wol->nr = 0;
|
|
|
|
}
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:33 +08:00
|
|
|
static void diff_filespec_load_driver(struct diff_filespec *one,
|
|
|
|
struct index_state *istate)
|
2012-03-15 02:24:08 +08:00
|
|
|
{
|
|
|
|
/* Use already-loaded driver */
|
|
|
|
if (one->driver)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (S_ISREG(one->mode))
|
2018-09-21 23:57:33 +08:00
|
|
|
one->driver = userdiff_find_by_path(istate, one->path);
|
2012-03-15 02:24:08 +08:00
|
|
|
|
|
|
|
/* Fallback to default settings */
|
|
|
|
if (!one->driver)
|
|
|
|
one->driver = userdiff_find_by_name("default");
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:33 +08:00
|
|
|
static const char *userdiff_word_regex(struct diff_filespec *one,
|
|
|
|
struct index_state *istate)
|
2012-03-15 02:24:08 +08:00
|
|
|
{
|
2018-09-21 23:57:33 +08:00
|
|
|
diff_filespec_load_driver(one, istate);
|
2012-03-15 02:24:08 +08:00
|
|
|
return one->driver->word_regex;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void init_diff_words_data(struct emit_callback *ecbdata,
|
2012-03-15 02:24:09 +08:00
|
|
|
struct diff_options *orig_opts,
|
2012-03-15 02:24:08 +08:00
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two)
|
|
|
|
{
|
|
|
|
int i;
|
2012-03-15 02:24:09 +08:00
|
|
|
struct diff_options *o = xmalloc(sizeof(struct diff_options));
|
|
|
|
memcpy(o, orig_opts, sizeof(struct diff_options));
|
2012-03-15 02:24:08 +08:00
|
|
|
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(ecbdata->diff_words, 1);
|
2012-03-15 02:24:08 +08:00
|
|
|
ecbdata->diff_words->type = o->word_diff;
|
|
|
|
ecbdata->diff_words->opt = o;
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
if (orig_opts->emitted_symbols)
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(o->emitted_symbols, 1);
|
2017-06-30 08:07:06 +08:00
|
|
|
|
2012-03-15 02:24:08 +08:00
|
|
|
if (!o->word_regex)
|
2018-09-21 23:57:33 +08:00
|
|
|
o->word_regex = userdiff_word_regex(one, o->repo->index);
|
2012-03-15 02:24:08 +08:00
|
|
|
if (!o->word_regex)
|
2018-09-21 23:57:33 +08:00
|
|
|
o->word_regex = userdiff_word_regex(two, o->repo->index);
|
2012-03-15 02:24:08 +08:00
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = diff_word_regex_cfg;
|
|
|
|
if (o->word_regex) {
|
|
|
|
ecbdata->diff_words->word_regex = (regex_t *)
|
|
|
|
xmalloc(sizeof(regex_t));
|
|
|
|
if (regcomp(ecbdata->diff_words->word_regex,
|
|
|
|
o->word_regex,
|
|
|
|
REG_EXTENDED | REG_NEWLINE))
|
2018-07-21 15:49:19 +08:00
|
|
|
die("invalid regular expression: %s",
|
|
|
|
o->word_regex);
|
2012-03-15 02:24:08 +08:00
|
|
|
}
|
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_words_styles); i++) {
|
|
|
|
if (o->word_diff == diff_words_styles[i].type) {
|
|
|
|
ecbdata->diff_words->style =
|
|
|
|
&diff_words_styles[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (want_color(o->use_color)) {
|
|
|
|
struct diff_words_style *st = ecbdata->diff_words->style;
|
2018-02-15 02:59:39 +08:00
|
|
|
st->old_word.color = diff_get_color_opt(o, DIFF_FILE_OLD);
|
|
|
|
st->new_word.color = diff_get_color_opt(o, DIFF_FILE_NEW);
|
2015-05-28 04:48:46 +08:00
|
|
|
st->ctx.color = diff_get_color_opt(o, DIFF_CONTEXT);
|
2012-03-15 02:24:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-29 05:56:15 +08:00
|
|
|
static void free_diff_words_data(struct emit_callback *ecbdata)
|
|
|
|
{
|
|
|
|
if (ecbdata->diff_words) {
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
diff_words_flush(ecbdata);
|
diff.c: fix a double-free regression in a18d66cefb
My a18d66cefb9 (diff.c: free "buf" in diff_words_flush(), 2022-03-04)
has what it retrospect is a rather obvious bug (I don't know what I
was thinking, if it all): We use the "emitted_symbols" allocation in
append_emitted_diff_symbol() N times, but starting with a18d66cefb9
we'd free it after its first use!
The correct way to free this data would have been to add the free() to
the existing free_diff_words_data() function, so let's do that. The
"ecbdata->diff_words->opt->emitted_symbols" might be NULL, so let's
add a trivial free_emitted_diff_symbols() helper next to the function
that appends to it.
This fixes the "no effect on show from" leak tested for in the
preceding commit. Perhaps confusingly this change will skip that test
under SANITIZE=leak, but otherwise opt-in the
"t4015-diff-whitespace.sh" test.
The reason is that a18d66cefb9 "fixed" the leak in the preceding "no
effect on diff" test, but for the first call to diff_words_flush() the
"wol->buf" would be NULL, so we wouldn't double-free (and
SANITIZE=address would see nothing amiss). With this change we'll
still pass that test, showing that we've also fixed leaks on this
codepath.
We then have to skip the new "no effect on show" test because it
happens to trip over an unrelated memory leak (in revision.c). The
same goes for "move detection with submodules". Both of them pass with
SANITIZE=address though, which would error on the "no effect on show"
test before this change.
Reported-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17 22:55:35 +08:00
|
|
|
free_emitted_diff_symbols(ecbdata->diff_words->opt->emitted_symbols);
|
2012-03-15 02:24:09 +08:00
|
|
|
free (ecbdata->diff_words->opt);
|
Avoid unnecessary "if-before-free" tests.
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
FYI, the change below was prepared by running the following:
git ls-files -z | xargs -0 \
perl -0x3b -pi -e \
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
Addendum:
Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 01:26:32 +08:00
|
|
|
free (ecbdata->diff_words->minus.text.ptr);
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
free (ecbdata->diff_words->minus.orig);
|
Avoid unnecessary "if-before-free" tests.
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
FYI, the change below was prepared by running the following:
git ls-files -z | xargs -0 \
perl -0x3b -pi -e \
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
Addendum:
Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 01:26:32 +08:00
|
|
|
free (ecbdata->diff_words->plus.text.ptr);
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 00:29:44 +08:00
|
|
|
free (ecbdata->diff_words->plus.orig);
|
2010-09-10 03:02:45 +08:00
|
|
|
if (ecbdata->diff_words->word_regex) {
|
|
|
|
regfree(ecbdata->diff_words->word_regex);
|
|
|
|
free(ecbdata->diff_words->word_regex);
|
|
|
|
}
|
2017-06-16 07:15:46 +08:00
|
|
|
FREE_AND_NULL(ecbdata->diff_words);
|
2006-07-29 05:56:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-23 17:24:18 +08:00
|
|
|
const char *diff_get_color(int diff_use_color, enum color_diff ix)
|
2006-06-14 00:45:44 +08:00
|
|
|
{
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 13:04:23 +08:00
|
|
|
if (want_color(diff_use_color))
|
Tweak diff colors
This patch does:
- always reset the color _before_ printing out the newline.
This is actually important. You (and Johannes) didn't see it, because
it only matters if you set the background, but if you don't do this,
you get some random and funky behaviour if you pick a color with a
non-default background (which still potentially has problems with tabs
etc, but less so).
- allow people to have a different color for the "file headers"
(DIFF_METAINFO) and for the "fragment header" (DIFF_FRAGINFO). Also,
make a difference between "normal color" and "reset colors"
- default to red/green for old/new lines. That's the norm, I'd think.
- instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping)
purple color for metadata, use bold-face for file headers, and cyan for
the frag headers. I actually prefer the "gray background" for that, but
it only works well in xterms, so COLOR_CYAN it is..
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23 04:53:31 +08:00
|
|
|
return diff_colors[ix];
|
|
|
|
return "";
|
2006-06-14 00:45:44 +08:00
|
|
|
}
|
|
|
|
|
2013-02-08 04:15:26 +08:00
|
|
|
const char *diff_line_prefix(struct diff_options *opt)
|
|
|
|
{
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
if (!opt->output_prefix)
|
|
|
|
return "";
|
|
|
|
|
|
|
|
msgbuf = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
return msgbuf->buf;
|
|
|
|
}
|
|
|
|
|
2019-02-14 13:48:27 +08:00
|
|
|
static unsigned long sane_truncate_line(char *line, unsigned long len)
|
2008-01-02 17:50:11 +08:00
|
|
|
{
|
|
|
|
const char *cp;
|
|
|
|
unsigned long allot;
|
|
|
|
size_t l = len;
|
|
|
|
|
|
|
|
cp = line;
|
|
|
|
allot = l;
|
|
|
|
while (0 < l) {
|
|
|
|
(void) utf8_width(&cp, &l);
|
|
|
|
if (!cp)
|
|
|
|
break; /* truncated in the middle? */
|
|
|
|
}
|
|
|
|
return allot - l;
|
|
|
|
}
|
|
|
|
|
2009-09-15 13:05:57 +08:00
|
|
|
static void find_lno(const char *line, struct emit_callback *ecbdata)
|
2009-09-04 15:41:15 +08:00
|
|
|
{
|
2009-09-15 13:05:57 +08:00
|
|
|
const char *p;
|
|
|
|
ecbdata->lno_in_preimage = 0;
|
|
|
|
ecbdata->lno_in_postimage = 0;
|
|
|
|
p = strchr(line, '-');
|
2009-09-04 15:41:15 +08:00
|
|
|
if (!p)
|
2009-09-15 13:05:57 +08:00
|
|
|
return; /* cannot happen */
|
|
|
|
ecbdata->lno_in_preimage = strtol(p + 1, NULL, 10);
|
|
|
|
p = strchr(p, '+');
|
|
|
|
if (!p)
|
|
|
|
return; /* cannot happen */
|
|
|
|
ecbdata->lno_in_postimage = strtol(p + 1, NULL, 10);
|
2009-09-04 15:41:15 +08:00
|
|
|
}
|
|
|
|
|
2021-04-13 01:15:24 +08:00
|
|
|
static int fn_out_consume(void *priv, char *line, unsigned long len)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct emit_callback *ecbdata = priv;
|
2010-05-26 15:23:54 +08:00
|
|
|
struct diff_options *o = ecbdata->opt;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2016-09-08 07:36:46 +08:00
|
|
|
o->found_changes = 1;
|
|
|
|
|
2009-11-20 05:12:24 +08:00
|
|
|
if (ecbdata->header) {
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
ecbdata->header->buf, ecbdata->header->len, 0);
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_reset(ecbdata->header);
|
|
|
|
ecbdata->header = NULL;
|
|
|
|
}
|
2007-02-26 06:34:54 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (ecbdata->label_path[0]) {
|
2017-06-30 08:06:56 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_FILEPAIR_MINUS,
|
|
|
|
ecbdata->label_path[0],
|
|
|
|
strlen(ecbdata->label_path[0]), 0);
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_FILEPAIR_PLUS,
|
|
|
|
ecbdata->label_path[1],
|
|
|
|
strlen(ecbdata->label_path[1]), 0);
|
2006-04-22 14:57:45 +08:00
|
|
|
ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
|
|
|
|
}
|
2006-06-14 00:45:44 +08:00
|
|
|
|
2008-08-15 19:39:26 +08:00
|
|
|
if (diff_suppress_blank_empty
|
|
|
|
&& len == 2 && line[0] == ' ' && line[1] == '\n') {
|
|
|
|
line[0] = '\n';
|
|
|
|
len = 1;
|
|
|
|
}
|
|
|
|
|
2009-09-04 14:59:25 +08:00
|
|
|
if (line[0] == '@') {
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
if (ecbdata->diff_words)
|
|
|
|
diff_words_flush(ecbdata);
|
2019-02-14 13:48:27 +08:00
|
|
|
len = sane_truncate_line(line, len);
|
2009-09-15 13:05:57 +08:00
|
|
|
find_lno(line, ecbdata);
|
2009-11-27 14:55:18 +08:00
|
|
|
emit_hunk_header(ecbdata, line, len);
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-06-14 00:45:44 +08:00
|
|
|
}
|
2006-09-23 13:48:39 +08:00
|
|
|
|
|
|
|
if (ecbdata->diff_words) {
|
2017-06-30 08:06:54 +08:00
|
|
|
enum diff_symbol s =
|
|
|
|
ecbdata->diff_words->type == DIFF_WORDS_PORCELAIN ?
|
|
|
|
DIFF_SYMBOL_WORDS_PORCELAIN : DIFF_SYMBOL_WORDS;
|
2006-09-23 13:48:39 +08:00
|
|
|
if (line[0] == '-') {
|
|
|
|
diff_words_append(line, len,
|
|
|
|
&ecbdata->diff_words->minus);
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-09-23 13:48:39 +08:00
|
|
|
} else if (line[0] == '+') {
|
|
|
|
diff_words_append(line, len,
|
|
|
|
&ecbdata->diff_words->plus);
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2013-12-01 04:55:40 +08:00
|
|
|
} else if (starts_with(line, "\\ ")) {
|
2012-01-12 19:15:33 +08:00
|
|
|
/*
|
|
|
|
* Eat the "no newline at eof" marker as if we
|
|
|
|
* saw a "+" or "-" line with nothing on it,
|
|
|
|
* and return without diff_words_flush() to
|
|
|
|
* defer processing. If this is the end of
|
|
|
|
* preimage, more "+" lines may come after it.
|
|
|
|
*/
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-09-23 13:48:39 +08:00
|
|
|
}
|
diff --color-words: bit of clean-up
When we introduced the "word diff" mode, we could have done one of three
things:
* change fn_out_consume() to "this is called every time a line worth of
diff becomes ready from the lower-level diff routine. This function
knows two sets of helpers (one for line-oriented diff, another for word
diff), and each set has various functions to be called at certain
places (e.g. hunk header, context, ...). The function's role is to
inspect the incoming line, and dispatch appropriate helpers to produce
either line- or word- oriented diff output."
* introduce fn_out_consume_word_diff() that is "this is called every time
a line worth of diff becomes ready from the lower-level diff routine,
and here is what we do to prepare word oriented diff using that line."
without touching fn_out_consume() at all.
* Do neither of the above, and keep fn_out_consume() to "this is called
every time a line worth of diff becomes ready from the lower-level diff
routine, and here is what we do to output line oriented diff using that
line." but sprinkle a handful of 'are we in word-diff mode? if so do
this totally different thing' at random places.
This patch is to at least abstract the details of "this totally different
thing" out from the main codepath, in order to improve readability.
We can later refactor it by introducing fn_out_consume_word_diff(), taking
the second route above, but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:09:06 +08:00
|
|
|
diff_words_flush(ecbdata);
|
2017-06-30 08:06:54 +08:00
|
|
|
emit_diff_symbol(o, s, line, len, 0);
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-09-23 13:48:39 +08:00
|
|
|
}
|
|
|
|
|
2015-05-27 00:56:33 +08:00
|
|
|
switch (line[0]) {
|
|
|
|
case '+':
|
2009-09-15 13:05:57 +08:00
|
|
|
ecbdata->lno_in_postimage++;
|
2019-02-14 13:48:13 +08:00
|
|
|
emit_add_line(ecbdata, line + 1, len - 1);
|
2015-05-27 00:56:33 +08:00
|
|
|
break;
|
|
|
|
case '-':
|
|
|
|
ecbdata->lno_in_preimage++;
|
2019-02-14 13:48:13 +08:00
|
|
|
emit_del_line(ecbdata, line + 1, len - 1);
|
2015-05-27 00:56:33 +08:00
|
|
|
break;
|
|
|
|
case ' ':
|
|
|
|
ecbdata->lno_in_postimage++;
|
|
|
|
ecbdata->lno_in_preimage++;
|
2019-02-14 13:48:13 +08:00
|
|
|
emit_context_line(ecbdata, line + 1, len - 1);
|
2015-05-27 00:56:33 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* incomplete line at the end */
|
|
|
|
ecbdata->lno_in_preimage++;
|
2017-06-30 08:06:55 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_CONTEXT_INCOMPLETE,
|
|
|
|
line, len, 0);
|
2015-05-27 00:56:33 +08:00
|
|
|
break;
|
2006-09-23 13:48:39 +08:00
|
|
|
}
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-02-01 21:02:20 +08:00
|
|
|
static void pprint_rename(struct strbuf *name, const char *a, const char *b)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2018-02-15 02:59:39 +08:00
|
|
|
const char *old_name = a;
|
|
|
|
const char *new_name = b;
|
2006-04-22 14:57:45 +08:00
|
|
|
int pfx_length, sfx_length;
|
2013-02-27 04:47:01 +08:00
|
|
|
int pfx_adjust_for_slash;
|
2006-04-22 14:57:45 +08:00
|
|
|
int len_a = strlen(a);
|
|
|
|
int len_b = strlen(b);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
int a_midlen, b_midlen;
|
2007-02-10 22:39:00 +08:00
|
|
|
int qlen_a = quote_c_style(a, NULL, NULL, 0);
|
|
|
|
int qlen_b = quote_c_style(b, NULL, NULL, 0);
|
|
|
|
|
|
|
|
if (qlen_a || qlen_b) {
|
2018-02-01 21:02:20 +08:00
|
|
|
quote_c_style(a, name, NULL, 0);
|
|
|
|
strbuf_addstr(name, " => ");
|
|
|
|
quote_c_style(b, name, NULL, 0);
|
|
|
|
return;
|
2007-02-10 22:39:00 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
/* Find common prefix */
|
|
|
|
pfx_length = 0;
|
2018-02-15 02:59:39 +08:00
|
|
|
while (*old_name && *new_name && *old_name == *new_name) {
|
|
|
|
if (*old_name == '/')
|
|
|
|
pfx_length = old_name - a + 1;
|
|
|
|
old_name++;
|
|
|
|
new_name++;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Find common suffix */
|
2018-02-15 02:59:39 +08:00
|
|
|
old_name = a + len_a;
|
|
|
|
new_name = b + len_b;
|
2006-04-22 14:57:45 +08:00
|
|
|
sfx_length = 0;
|
2013-02-24 00:48:45 +08:00
|
|
|
/*
|
2013-02-27 04:47:01 +08:00
|
|
|
* If there is a common prefix, it must end in a slash. In
|
|
|
|
* that case we let this loop run 1 into the prefix to see the
|
|
|
|
* same slash.
|
|
|
|
*
|
|
|
|
* If there is no common prefix, we cannot do this as it would
|
|
|
|
* underrun the input strings.
|
2013-02-24 00:48:45 +08:00
|
|
|
*/
|
2013-02-27 04:47:01 +08:00
|
|
|
pfx_adjust_for_slash = (pfx_length ? 1 : 0);
|
2018-02-15 02:59:39 +08:00
|
|
|
while (a + pfx_length - pfx_adjust_for_slash <= old_name &&
|
|
|
|
b + pfx_length - pfx_adjust_for_slash <= new_name &&
|
|
|
|
*old_name == *new_name) {
|
|
|
|
if (*old_name == '/')
|
|
|
|
sfx_length = len_a - (old_name - a);
|
|
|
|
old_name--;
|
|
|
|
new_name--;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pfx{mid-a => mid-b}sfx
|
|
|
|
* {pfx-a => pfx-b}sfx
|
|
|
|
* pfx{sfx-a => sfx-b}
|
|
|
|
* name-a => name-b
|
|
|
|
*/
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
a_midlen = len_a - pfx_length - sfx_length;
|
|
|
|
b_midlen = len_b - pfx_length - sfx_length;
|
|
|
|
if (a_midlen < 0)
|
|
|
|
a_midlen = 0;
|
|
|
|
if (b_midlen < 0)
|
|
|
|
b_midlen = 0;
|
|
|
|
|
2018-02-01 21:02:20 +08:00
|
|
|
strbuf_grow(name, pfx_length + a_midlen + b_midlen + sfx_length + 7);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (pfx_length + sfx_length) {
|
2018-02-01 21:02:20 +08:00
|
|
|
strbuf_add(name, a, pfx_length);
|
|
|
|
strbuf_addch(name, '{');
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2018-02-01 21:02:20 +08:00
|
|
|
strbuf_add(name, a + pfx_length, a_midlen);
|
|
|
|
strbuf_addstr(name, " => ");
|
|
|
|
strbuf_add(name, b + pfx_length, b_midlen);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
if (pfx_length + sfx_length) {
|
2018-02-01 21:02:20 +08:00
|
|
|
strbuf_addch(name, '}');
|
|
|
|
strbuf_add(name, a + len_a - sfx_length, sfx_length);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct diffstat_file *diffstat_add(struct diffstat_t *diffstat,
|
|
|
|
const char *name_a,
|
|
|
|
const char *name_b)
|
|
|
|
{
|
|
|
|
struct diffstat_file *x;
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(x, 1);
|
2014-03-04 06:31:53 +08:00
|
|
|
ALLOC_GROW(diffstat->files, diffstat->nr + 1, diffstat->alloc);
|
2006-04-22 14:57:45 +08:00
|
|
|
diffstat->files[diffstat->nr++] = x;
|
|
|
|
if (name_b) {
|
2007-12-12 15:46:30 +08:00
|
|
|
x->from_name = xstrdup(name_a);
|
|
|
|
x->name = xstrdup(name_b);
|
2006-04-22 14:57:45 +08:00
|
|
|
x->is_renamed = 1;
|
|
|
|
}
|
2007-12-12 15:46:30 +08:00
|
|
|
else {
|
|
|
|
x->from_name = NULL;
|
2006-09-02 12:16:31 +08:00
|
|
|
x->name = xstrdup(name_a);
|
2007-12-12 15:46:30 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
2021-04-13 01:15:24 +08:00
|
|
|
static int diffstat_consume(void *priv, char *line, unsigned long len)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct diffstat_t *diffstat = priv;
|
|
|
|
struct diffstat_file *x = diffstat->files[diffstat->nr - 1];
|
|
|
|
|
|
|
|
if (line[0] == '+')
|
|
|
|
x->added++;
|
|
|
|
else if (line[0] == '-')
|
|
|
|
x->deleted++;
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-05-20 21:40:29 +08:00
|
|
|
const char mime_boundary_leader[] = "------------";
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-09-27 09:53:02 +08:00
|
|
|
static int scale_linear(int it, int width, int max_change)
|
|
|
|
{
|
2012-02-15 05:49:11 +08:00
|
|
|
if (!it)
|
|
|
|
return 0;
|
2006-09-27 09:53:02 +08:00
|
|
|
/*
|
2012-02-15 05:49:11 +08:00
|
|
|
* make sure that at least one '-' or '+' is printed if
|
|
|
|
* there is any change to this path. The easiest way is to
|
2019-11-06 01:07:23 +08:00
|
|
|
* scale linearly as if the allotted width is one column shorter
|
2012-02-15 05:49:11 +08:00
|
|
|
* than it is, and then add 1 to the result.
|
2006-09-27 09:53:02 +08:00
|
|
|
*/
|
2012-02-15 05:49:11 +08:00
|
|
|
return 1 + (it * (width - 1) / max_change);
|
2006-09-27 09:53:02 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:02 +08:00
|
|
|
static void show_graph(struct strbuf *out, char ch, int cnt,
|
|
|
|
const char *set, const char *reset)
|
2006-09-27 09:53:02 +08:00
|
|
|
{
|
|
|
|
if (cnt <= 0)
|
|
|
|
return;
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addstr(out, set);
|
|
|
|
strbuf_addchars(out, ch, cnt);
|
|
|
|
strbuf_addstr(out, reset);
|
2006-09-27 09:53:02 +08:00
|
|
|
}
|
|
|
|
|
2007-12-12 15:46:30 +08:00
|
|
|
static void fill_print_name(struct diffstat_file *file)
|
|
|
|
{
|
2018-02-01 21:02:20 +08:00
|
|
|
struct strbuf pname = STRBUF_INIT;
|
2007-12-12 15:46:30 +08:00
|
|
|
|
|
|
|
if (file->print_name)
|
|
|
|
return;
|
|
|
|
|
2018-02-01 21:02:20 +08:00
|
|
|
if (file->is_renamed)
|
|
|
|
pprint_rename(&pname, file->from_name, file->name);
|
|
|
|
else
|
|
|
|
quote_c_style(file->name, &pname, NULL, 0);
|
|
|
|
|
2018-02-24 22:09:59 +08:00
|
|
|
if (file->comments)
|
|
|
|
strbuf_addf(&pname, " (%s)", file->comments);
|
|
|
|
|
2018-02-01 21:02:20 +08:00
|
|
|
file->print_name = strbuf_detach(&pname, NULL);
|
2007-12-12 15:46:30 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:02 +08:00
|
|
|
static void print_stat_summary_inserts_deletes(struct diff_options *options,
|
|
|
|
int files, int insertions, int deletions)
|
2012-02-01 20:55:07 +08:00
|
|
|
{
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
if (!files) {
|
|
|
|
assert(insertions == 0 && deletions == 0);
|
2017-06-30 08:07:02 +08:00
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_SUMMARY_NO_FILES,
|
|
|
|
NULL, 0, 0);
|
|
|
|
return;
|
2012-02-01 20:55:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_addf(&sb,
|
2012-09-13 22:16:26 +08:00
|
|
|
(files == 1) ? " %d file changed" : " %d files changed",
|
2012-02-01 20:55:07 +08:00
|
|
|
files);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For binary diff, the caller may want to print "x files
|
|
|
|
* changed" with insertions == 0 && deletions == 0.
|
|
|
|
*
|
|
|
|
* Not omitting "0 insertions(+), 0 deletions(-)" in this case
|
|
|
|
* is probably less confusing (i.e skip over "2 files changed
|
|
|
|
* but nothing about added/removed lines? Is this a bug in Git?").
|
|
|
|
*/
|
|
|
|
if (insertions || deletions == 0) {
|
|
|
|
strbuf_addf(&sb,
|
2012-09-13 22:16:26 +08:00
|
|
|
(insertions == 1) ? ", %d insertion(+)" : ", %d insertions(+)",
|
2012-02-01 20:55:07 +08:00
|
|
|
insertions);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (deletions || insertions == 0) {
|
|
|
|
strbuf_addf(&sb,
|
2012-09-13 22:16:26 +08:00
|
|
|
(deletions == 1) ? ", %d deletion(-)" : ", %d deletions(-)",
|
2012-02-01 20:55:07 +08:00
|
|
|
deletions);
|
|
|
|
}
|
|
|
|
strbuf_addch(&sb, '\n');
|
2017-06-30 08:07:02 +08:00
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_SUMMARY_INSERTS_DELETES,
|
|
|
|
sb.buf, sb.len, 0);
|
2012-02-01 20:55:07 +08:00
|
|
|
strbuf_release(&sb);
|
2017-06-30 08:07:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void print_stat_summary(FILE *fp, int files,
|
|
|
|
int insertions, int deletions)
|
|
|
|
{
|
|
|
|
struct diff_options o;
|
|
|
|
memset(&o, 0, sizeof(o));
|
|
|
|
o.file = fp;
|
|
|
|
|
|
|
|
print_stat_summary_inserts_deletes(&o, files, insertions, deletions);
|
2012-02-01 20:55:07 +08:00
|
|
|
}
|
|
|
|
|
2009-05-01 17:06:36 +08:00
|
|
|
static void show_stats(struct diffstat_t *data, struct diff_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2009-03-08 04:02:10 +08:00
|
|
|
int i, len, add, del, adds = 0, dels = 0;
|
2010-04-18 01:41:08 +08:00
|
|
|
uintmax_t max_change = 0, max_len = 0;
|
2012-05-01 04:38:58 +08:00
|
|
|
int total_files = data->nr, count;
|
|
|
|
int width, name_width, graph_width, number_width = 0, bin_width = 0;
|
2011-03-22 20:50:08 +08:00
|
|
|
const char *reset, *add_c, *del_c;
|
2011-05-28 12:50:39 +08:00
|
|
|
int extra_shown = 0;
|
2017-06-30 08:07:02 +08:00
|
|
|
const char *line_prefix = diff_line_prefix(options);
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
2011-05-27 20:36:41 +08:00
|
|
|
count = options->stat_count ? options->stat_count : data->nr;
|
2006-09-27 09:53:02 +08:00
|
|
|
|
2007-11-11 03:05:14 +08:00
|
|
|
reset = diff_get_color_opt(options, DIFF_RESET);
|
|
|
|
add_c = diff_get_color_opt(options, DIFF_FILE_NEW);
|
|
|
|
del_c = diff_get_color_opt(options, DIFF_FILE_OLD);
|
2006-09-27 09:59:41 +08:00
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
/*
|
|
|
|
* Find the longest filename and max number of changes
|
|
|
|
*/
|
2011-05-27 20:36:41 +08:00
|
|
|
for (i = 0; (i < count) && (i < data->nr); i++) {
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diffstat_file *file = data->files[i];
|
2010-04-18 01:41:08 +08:00
|
|
|
uintmax_t change = file->added + file->deleted;
|
2012-11-28 03:24:54 +08:00
|
|
|
|
|
|
|
if (!file->is_interesting && (change == 0)) {
|
2011-05-27 20:36:41 +08:00
|
|
|
count++; /* not shown == room for one more */
|
2011-05-27 20:36:40 +08:00
|
|
|
continue;
|
|
|
|
}
|
2007-12-12 15:46:30 +08:00
|
|
|
fill_print_name(file);
|
|
|
|
len = strlen(file->print_name);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (max_len < len)
|
|
|
|
max_len = len;
|
|
|
|
|
2012-05-01 04:38:58 +08:00
|
|
|
if (file->is_unmerged) {
|
|
|
|
/* "Unmerged" is 8 characters */
|
|
|
|
bin_width = bin_width < 8 ? 8 : bin_width;
|
2006-04-22 14:57:45 +08:00
|
|
|
continue;
|
2012-05-01 04:38:58 +08:00
|
|
|
}
|
|
|
|
if (file->is_binary) {
|
|
|
|
/* "Bin XXX -> YYY bytes" */
|
|
|
|
int w = 14 + decimal_width(file->added)
|
|
|
|
+ decimal_width(file->deleted);
|
|
|
|
bin_width = bin_width < w ? w : bin_width;
|
|
|
|
/* Display change counts aligned with "Bin" */
|
|
|
|
number_width = 3;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2006-09-27 09:53:02 +08:00
|
|
|
if (max_change < change)
|
|
|
|
max_change = change;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2012-11-28 03:47:46 +08:00
|
|
|
count = i; /* where we can stop scanning in data->files[] */
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
/*
|
|
|
|
* We have width = stat_width or term_columns() columns total.
|
|
|
|
* We want a maximum of min(max_len, stat_name_width) for the name part.
|
2012-03-01 20:26:45 +08:00
|
|
|
* We want a maximum of min(max_change, stat_graph_width) for the +- part.
|
2012-03-01 20:26:43 +08:00
|
|
|
* We also need 1 for " " and 4 + decimal_width(max_change)
|
|
|
|
* for " | NNNN " and one the empty column at the end, altogether
|
|
|
|
* 6 + decimal_width(max_change).
|
|
|
|
*
|
|
|
|
* If there's not enough space, we will use the smaller of
|
|
|
|
* stat_name_width (if set) and 5/8*width for the filename,
|
2012-03-01 20:26:45 +08:00
|
|
|
* and the rest for constant elements + graph part, but no more
|
|
|
|
* than stat_graph_width for the graph part.
|
2012-03-01 20:26:43 +08:00
|
|
|
* (5/8 gives 50 for filename and 30 for the constant parts + graph
|
|
|
|
* for the standard terminal size).
|
2006-09-27 09:53:02 +08:00
|
|
|
*
|
2012-03-01 20:26:43 +08:00
|
|
|
* In other words: stat_width limits the maximum width, and
|
|
|
|
* stat_name_width fixes the maximum width of the filename,
|
|
|
|
* and is also used to divide available columns if there
|
|
|
|
* aren't enough.
|
2012-05-01 04:38:58 +08:00
|
|
|
*
|
|
|
|
* Binary files are displayed with "Bin XXX -> YYY bytes"
|
|
|
|
* instead of the change count and graph. This part is treated
|
|
|
|
* similarly to the graph part, except that it is not
|
2013-04-12 06:36:10 +08:00
|
|
|
* "scaled". If total width is too small to accommodate the
|
2012-05-01 04:38:58 +08:00
|
|
|
* guaranteed minimum width of the filename part and the
|
|
|
|
* separators and this message, this message will "overflow"
|
|
|
|
* making the line longer than the maximum width.
|
2006-09-27 09:53:02 +08:00
|
|
|
*/
|
2012-03-01 20:26:43 +08:00
|
|
|
|
|
|
|
if (options->stat_width == -1)
|
2016-09-01 07:27:19 +08:00
|
|
|
width = term_columns() - strlen(line_prefix);
|
2006-09-27 09:53:02 +08:00
|
|
|
else
|
2012-03-01 20:26:43 +08:00
|
|
|
width = options->stat_width ? options->stat_width : 80;
|
2012-05-01 04:38:58 +08:00
|
|
|
number_width = decimal_width(max_change) > number_width ?
|
|
|
|
decimal_width(max_change) : number_width;
|
2006-09-27 09:53:02 +08:00
|
|
|
|
2012-03-01 20:26:46 +08:00
|
|
|
if (options->stat_graph_width == -1)
|
|
|
|
options->stat_graph_width = diff_stat_graph_width;
|
2006-09-27 09:53:02 +08:00
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
/*
|
|
|
|
* Guarantee 3/8*16==6 for the graph part
|
|
|
|
* and 5/8*16==10 for the filename part
|
|
|
|
*/
|
|
|
|
if (width < 16 + 6 + number_width)
|
|
|
|
width = 16 + 6 + number_width;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First assign sizes that are wanted, ignoring available width.
|
2012-05-01 04:38:58 +08:00
|
|
|
* strlen("Bin XXX -> YYY bytes") == bin_width, and the part
|
|
|
|
* starting from "XXX" should fit in graph_width.
|
2012-03-01 20:26:43 +08:00
|
|
|
*/
|
2012-05-01 04:38:58 +08:00
|
|
|
graph_width = max_change + 4 > bin_width ? max_change : bin_width - 4;
|
|
|
|
if (options->stat_graph_width &&
|
|
|
|
options->stat_graph_width < graph_width)
|
|
|
|
graph_width = options->stat_graph_width;
|
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
name_width = (options->stat_name_width > 0 &&
|
|
|
|
options->stat_name_width < max_len) ?
|
|
|
|
options->stat_name_width : max_len;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust adjustable widths not to exceed maximum width
|
|
|
|
*/
|
|
|
|
if (name_width + number_width + 6 + graph_width > width) {
|
2012-04-19 05:12:18 +08:00
|
|
|
if (graph_width > width * 3/8 - number_width - 6) {
|
2012-03-01 20:26:43 +08:00
|
|
|
graph_width = width * 3/8 - number_width - 6;
|
2012-04-19 05:12:18 +08:00
|
|
|
if (graph_width < 6)
|
|
|
|
graph_width = 6;
|
|
|
|
}
|
|
|
|
|
2012-03-01 20:26:45 +08:00
|
|
|
if (options->stat_graph_width &&
|
|
|
|
graph_width > options->stat_graph_width)
|
|
|
|
graph_width = options->stat_graph_width;
|
2012-03-01 20:26:43 +08:00
|
|
|
if (name_width > width - number_width - 6 - graph_width)
|
|
|
|
name_width = width - number_width - 6 - graph_width;
|
|
|
|
else
|
|
|
|
graph_width = width - number_width - 6 - name_width;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* From here name_width is the width of the name area,
|
|
|
|
* and graph_width is the width of the graph area.
|
|
|
|
* max_change is used to scale graph properly.
|
|
|
|
*/
|
2011-05-27 20:36:41 +08:00
|
|
|
for (i = 0; i < count; i++) {
|
2006-06-25 01:20:32 +08:00
|
|
|
const char *prefix = "";
|
2012-11-28 03:24:54 +08:00
|
|
|
struct diffstat_file *file = data->files[i];
|
|
|
|
char *name = file->print_name;
|
|
|
|
uintmax_t added = file->added;
|
|
|
|
uintmax_t deleted = file->deleted;
|
2006-09-27 09:53:02 +08:00
|
|
|
int name_len;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2012-11-28 03:47:46 +08:00
|
|
|
if (!file->is_interesting && (added + deleted == 0))
|
2011-05-27 20:36:40 +08:00
|
|
|
continue;
|
2012-11-28 03:47:46 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* "scale" the filename
|
|
|
|
*/
|
2006-09-27 09:53:02 +08:00
|
|
|
len = name_width;
|
|
|
|
name_len = strlen(name);
|
|
|
|
if (name_width < name_len) {
|
2006-04-22 14:57:45 +08:00
|
|
|
char *slash;
|
|
|
|
prefix = "...";
|
2006-09-27 09:53:02 +08:00
|
|
|
len -= 3;
|
|
|
|
name += name_len - len;
|
2006-04-22 14:57:45 +08:00
|
|
|
slash = strchr(name, '/');
|
|
|
|
if (slash)
|
|
|
|
name = slash;
|
|
|
|
}
|
|
|
|
|
2012-11-28 03:24:54 +08:00
|
|
|
if (file->is_binary) {
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addf(&out, " %s%-*s |", prefix, len, name);
|
|
|
|
strbuf_addf(&out, " %*s", number_width, "Bin");
|
2012-05-02 01:10:14 +08:00
|
|
|
if (!added && !deleted) {
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addch(&out, '\n');
|
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_LINE,
|
|
|
|
out.buf, out.len, 0);
|
|
|
|
strbuf_reset(&out);
|
2012-05-02 01:10:14 +08:00
|
|
|
continue;
|
|
|
|
}
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addf(&out, " %s%"PRIuMAX"%s",
|
2010-04-18 01:41:08 +08:00
|
|
|
del_c, deleted, reset);
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addstr(&out, " -> ");
|
|
|
|
strbuf_addf(&out, "%s%"PRIuMAX"%s",
|
2010-04-18 01:41:08 +08:00
|
|
|
add_c, added, reset);
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addstr(&out, " bytes\n");
|
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_LINE,
|
|
|
|
out.buf, out.len, 0);
|
|
|
|
strbuf_reset(&out);
|
2007-12-12 15:46:30 +08:00
|
|
|
continue;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2012-11-28 03:24:54 +08:00
|
|
|
else if (file->is_unmerged) {
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addf(&out, " %s%-*s |", prefix, len, name);
|
|
|
|
strbuf_addstr(&out, " Unmerged\n");
|
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_LINE,
|
|
|
|
out.buf, out.len, 0);
|
|
|
|
strbuf_reset(&out);
|
2007-12-12 15:46:30 +08:00
|
|
|
continue;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-09-27 09:53:02 +08:00
|
|
|
/*
|
|
|
|
* scale the add/delete
|
|
|
|
*/
|
2006-04-22 14:57:45 +08:00
|
|
|
add = added;
|
|
|
|
del = deleted;
|
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
if (graph_width <= max_change) {
|
2013-07-15 05:35:49 +08:00
|
|
|
int total = scale_linear(add + del, graph_width, max_change);
|
2012-02-15 05:49:11 +08:00
|
|
|
if (total < 2 && add && del)
|
|
|
|
/* width >= 2 due to the sanity check */
|
|
|
|
total = 2;
|
|
|
|
if (add < del) {
|
2012-03-01 20:26:43 +08:00
|
|
|
add = scale_linear(add, graph_width, max_change);
|
2012-02-15 05:49:11 +08:00
|
|
|
del = total - add;
|
|
|
|
} else {
|
2012-03-01 20:26:43 +08:00
|
|
|
del = scale_linear(del, graph_width, max_change);
|
2012-02-15 05:49:11 +08:00
|
|
|
add = total - del;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2017-06-30 08:07:02 +08:00
|
|
|
strbuf_addf(&out, " %s%-*s |", prefix, len, name);
|
|
|
|
strbuf_addf(&out, " %*"PRIuMAX"%s",
|
2012-05-01 04:38:58 +08:00
|
|
|
number_width, added + deleted,
|
|
|
|
added + deleted ? " " : "");
|
2017-06-30 08:07:02 +08:00
|
|
|
show_graph(&out, '+', add, add_c, reset);
|
|
|
|
show_graph(&out, '-', del, del_c, reset);
|
|
|
|
strbuf_addch(&out, '\n');
|
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STATS_LINE,
|
|
|
|
out.buf, out.len, 0);
|
|
|
|
strbuf_reset(&out);
|
2008-03-10 10:43:39 +08:00
|
|
|
}
|
2012-11-28 03:47:46 +08:00
|
|
|
|
|
|
|
for (i = 0; i < data->nr; i++) {
|
2012-11-28 03:24:54 +08:00
|
|
|
struct diffstat_file *file = data->files[i];
|
|
|
|
uintmax_t added = file->added;
|
|
|
|
uintmax_t deleted = file->deleted;
|
2012-11-28 04:05:10 +08:00
|
|
|
|
|
|
|
if (file->is_unmerged ||
|
|
|
|
(!file->is_interesting && (added + deleted == 0))) {
|
2011-05-27 20:36:41 +08:00
|
|
|
total_files--;
|
|
|
|
continue;
|
|
|
|
}
|
2012-11-28 03:47:46 +08:00
|
|
|
|
2012-11-28 04:05:10 +08:00
|
|
|
if (!file->is_binary) {
|
2012-11-28 03:47:46 +08:00
|
|
|
adds += added;
|
|
|
|
dels += deleted;
|
|
|
|
}
|
|
|
|
if (i < count)
|
|
|
|
continue;
|
2011-05-28 12:50:39 +08:00
|
|
|
if (!extra_shown)
|
2017-06-30 08:07:02 +08:00
|
|
|
emit_diff_symbol(options,
|
|
|
|
DIFF_SYMBOL_STATS_SUMMARY_ABBREV,
|
|
|
|
NULL, 0, 0);
|
2011-05-28 12:50:39 +08:00
|
|
|
extra_shown = 1;
|
2011-05-27 20:36:41 +08:00
|
|
|
}
|
2017-06-30 08:07:02 +08:00
|
|
|
|
|
|
|
print_stat_summary_inserts_deletes(options, total_files, adds, dels);
|
2017-08-31 01:49:43 +08:00
|
|
|
strbuf_release(&out);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2009-10-12 04:46:11 +08:00
|
|
|
static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
|
2006-12-15 12:15:44 +08:00
|
|
|
{
|
|
|
|
int i, adds = 0, dels = 0, total_files = data->nr;
|
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < data->nr; i++) {
|
2012-05-02 01:10:14 +08:00
|
|
|
int added = data->files[i]->added;
|
2017-06-30 08:07:02 +08:00
|
|
|
int deleted = data->files[i]->deleted;
|
2012-05-02 01:10:14 +08:00
|
|
|
|
2012-11-28 06:19:36 +08:00
|
|
|
if (data->files[i]->is_unmerged ||
|
|
|
|
(!data->files[i]->is_interesting && (added + deleted == 0))) {
|
2012-05-02 01:10:14 +08:00
|
|
|
total_files--;
|
2012-06-16 05:50:30 +08:00
|
|
|
} else if (!data->files[i]->is_binary) { /* don't count bytes */
|
2012-05-02 01:10:14 +08:00
|
|
|
adds += added;
|
|
|
|
dels += deleted;
|
2006-12-15 12:15:44 +08:00
|
|
|
}
|
|
|
|
}
|
2017-06-30 08:07:02 +08:00
|
|
|
print_stat_summary_inserts_deletes(options, total_files, adds, dels);
|
2006-12-15 12:15:44 +08:00
|
|
|
}
|
|
|
|
|
2009-05-01 17:06:36 +08:00
|
|
|
static void show_numstat(struct diffstat_t *data, struct diff_options *options)
|
2006-10-12 18:01:00 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2007-12-12 15:46:30 +08:00
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
2006-10-12 18:01:00 +08:00
|
|
|
for (i = 0; i < data->nr; i++) {
|
|
|
|
struct diffstat_file *file = data->files[i];
|
|
|
|
|
2013-02-08 04:15:27 +08:00
|
|
|
fprintf(options->file, "%s", diff_line_prefix(options));
|
2010-05-26 15:23:54 +08:00
|
|
|
|
2006-12-11 05:50:59 +08:00
|
|
|
if (file->is_binary)
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(options->file, "-\t-\t");
|
2006-12-11 05:50:59 +08:00
|
|
|
else
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(options->file,
|
2010-04-18 01:41:08 +08:00
|
|
|
"%"PRIuMAX"\t%"PRIuMAX"\t",
|
|
|
|
file->added, file->deleted);
|
2007-12-12 15:46:30 +08:00
|
|
|
if (options->line_termination) {
|
|
|
|
fill_print_name(file);
|
|
|
|
if (!file->is_renamed)
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(file->name, options->file,
|
2007-12-12 15:46:30 +08:00
|
|
|
options->line_termination);
|
|
|
|
else {
|
2008-03-10 10:43:39 +08:00
|
|
|
fputs(file->print_name, options->file);
|
|
|
|
putc(options->line_termination, options->file);
|
2007-12-12 15:46:30 +08:00
|
|
|
}
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
} else {
|
2007-12-12 15:46:30 +08:00
|
|
|
if (file->is_renamed) {
|
2008-03-10 10:43:39 +08:00
|
|
|
putc('\0', options->file);
|
|
|
|
write_name_quoted(file->from_name, options->file, '\0');
|
2007-12-12 15:46:30 +08:00
|
|
|
}
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(file->name, options->file, '\0');
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
}
|
2006-10-12 18:01:00 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-13 09:06:58 +08:00
|
|
|
struct dirstat_file {
|
|
|
|
const char *name;
|
|
|
|
unsigned long changed;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
};
|
|
|
|
|
2008-02-13 09:06:58 +08:00
|
|
|
struct dirstat_dir {
|
|
|
|
struct dirstat_file *files;
|
2011-04-29 17:36:20 +08:00
|
|
|
int alloc, nr, permille, cumulative;
|
2008-02-13 09:06:58 +08:00
|
|
|
};
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static long gather_dirstat(struct diff_options *opt, struct dirstat_dir *dir,
|
|
|
|
unsigned long changed, const char *base, int baselen)
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
{
|
2018-02-15 02:59:28 +08:00
|
|
|
unsigned long sum_changes = 0;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
unsigned int sources = 0;
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix = diff_line_prefix(opt);
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
|
|
|
|
while (dir->nr) {
|
2008-02-13 09:06:58 +08:00
|
|
|
struct dirstat_file *f = dir->files;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
int namelen = strlen(f->name);
|
2018-02-15 02:59:28 +08:00
|
|
|
unsigned long changes;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
char *slash;
|
|
|
|
|
|
|
|
if (namelen < baselen)
|
|
|
|
break;
|
|
|
|
if (memcmp(f->name, base, baselen))
|
|
|
|
break;
|
|
|
|
slash = strchr(f->name + baselen, '/');
|
|
|
|
if (slash) {
|
|
|
|
int newbaselen = slash + 1 - f->name;
|
2018-02-15 02:59:28 +08:00
|
|
|
changes = gather_dirstat(opt, dir, changed, f->name, newbaselen);
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
sources++;
|
|
|
|
} else {
|
2018-02-15 02:59:28 +08:00
|
|
|
changes = f->changed;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
dir->files++;
|
|
|
|
dir->nr--;
|
|
|
|
sources += 2;
|
|
|
|
}
|
2018-02-15 02:59:28 +08:00
|
|
|
sum_changes += changes;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't report dirstat's for
|
|
|
|
* - the top level
|
|
|
|
* - or cases where everything came from a single directory
|
|
|
|
* under this directory (sources == 1).
|
|
|
|
*/
|
|
|
|
if (baselen && sources != 1) {
|
2018-02-15 02:59:28 +08:00
|
|
|
if (sum_changes) {
|
|
|
|
int permille = sum_changes * 1000 / changed;
|
2011-04-29 17:36:20 +08:00
|
|
|
if (permille >= dir->permille) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(opt->file, "%s%4d.%01d%% %.*s\n", line_prefix,
|
2011-04-29 17:36:20 +08:00
|
|
|
permille / 10, permille % 10, baselen, base);
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
if (!dir->cumulative)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2018-02-15 02:59:28 +08:00
|
|
|
return sum_changes;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
}
|
|
|
|
|
2008-08-29 07:19:08 +08:00
|
|
|
static int dirstat_compare(const void *_a, const void *_b)
|
|
|
|
{
|
|
|
|
const struct dirstat_file *a = _a;
|
|
|
|
const struct dirstat_file *b = _b;
|
|
|
|
return strcmp(a->name, b->name);
|
|
|
|
}
|
|
|
|
|
2008-02-13 09:06:58 +08:00
|
|
|
static void show_dirstat(struct diff_options *options)
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long changed;
|
2008-02-13 09:06:58 +08:00
|
|
|
struct dirstat_dir dir;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
|
|
|
|
dir.files = NULL;
|
|
|
|
dir.alloc = 0;
|
|
|
|
dir.nr = 0;
|
2011-04-29 17:36:20 +08:00
|
|
|
dir.permille = options->dirstat_permille;
|
2017-11-01 02:19:11 +08:00
|
|
|
dir.cumulative = options->flags.dirstat_cumulative;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
|
|
|
|
changed = 0;
|
2008-02-13 09:06:58 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
const char *name;
|
|
|
|
unsigned long copied, added, damage;
|
2020-04-08 06:11:41 +08:00
|
|
|
struct diff_populate_filespec_options dpf_options = {
|
|
|
|
.check_size_only = 1,
|
|
|
|
};
|
2008-02-13 09:06:58 +08:00
|
|
|
|
2011-04-12 17:24:34 +08:00
|
|
|
name = p->two->path ? p->two->path : p->one->path;
|
2008-02-13 09:06:58 +08:00
|
|
|
|
2018-08-29 05:23:03 +08:00
|
|
|
if (p->one->oid_valid && p->two->oid_valid &&
|
|
|
|
oideq(&p->one->oid, &p->two->oid)) {
|
2011-04-11 06:48:52 +08:00
|
|
|
/*
|
|
|
|
* The SHA1 has not changed, so pre-/post-content is
|
|
|
|
* identical. We can therefore skip looking at the
|
|
|
|
* file contents altogether.
|
|
|
|
*/
|
|
|
|
damage = 0;
|
|
|
|
goto found_damage;
|
|
|
|
}
|
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.dirstat_by_file) {
|
2011-04-11 06:48:51 +08:00
|
|
|
/*
|
|
|
|
* In --dirstat-by-file mode, we don't really need to
|
|
|
|
* look at the actual file contents at all.
|
|
|
|
* The fact that the SHA1 changed is enough for us to
|
|
|
|
* add this file to the list of results
|
|
|
|
* (with each file contributing equal damage).
|
|
|
|
*/
|
2011-04-11 06:48:52 +08:00
|
|
|
damage = 1;
|
2011-04-11 06:48:51 +08:00
|
|
|
goto found_damage;
|
|
|
|
}
|
2008-02-13 09:06:58 +08:00
|
|
|
|
|
|
|
if (DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two)) {
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(options->repo, p->one, NULL);
|
|
|
|
diff_populate_filespec(options->repo, p->two, NULL);
|
2018-09-21 23:57:19 +08:00
|
|
|
diffcore_count_changes(options->repo,
|
|
|
|
p->one, p->two, NULL, NULL,
|
2008-02-13 09:06:58 +08:00
|
|
|
&copied, &added);
|
|
|
|
diff_free_filespec_data(p->one);
|
|
|
|
diff_free_filespec_data(p->two);
|
|
|
|
} else if (DIFF_FILE_VALID(p->one)) {
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(options->repo, p->one, &dpf_options);
|
2008-02-13 09:06:58 +08:00
|
|
|
copied = added = 0;
|
|
|
|
diff_free_filespec_data(p->one);
|
|
|
|
} else if (DIFF_FILE_VALID(p->two)) {
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(options->repo, p->two, &dpf_options);
|
2008-02-13 09:06:58 +08:00
|
|
|
copied = 0;
|
|
|
|
added = p->two->size;
|
|
|
|
diff_free_filespec_data(p->two);
|
|
|
|
} else
|
2008-02-25 09:37:15 +08:00
|
|
|
continue;
|
2008-02-13 09:06:58 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Original minus copied is the removed material,
|
|
|
|
* added is the new material. They are both damages
|
2011-04-11 06:48:51 +08:00
|
|
|
* made to the preimage.
|
2011-04-11 06:48:52 +08:00
|
|
|
* If the resulting damage is zero, we know that
|
|
|
|
* diffcore_count_changes() considers the two entries to
|
2018-08-29 05:23:03 +08:00
|
|
|
* be identical, but since the oid changed, we
|
2011-04-11 06:48:52 +08:00
|
|
|
* know that there must have been _some_ kind of change,
|
|
|
|
* so we force all entries to have damage > 0.
|
2008-02-13 09:06:58 +08:00
|
|
|
*/
|
|
|
|
damage = (p->one->size - copied) + added;
|
2011-04-11 06:48:52 +08:00
|
|
|
if (!damage)
|
2008-09-06 03:27:35 +08:00
|
|
|
damage = 1;
|
2008-02-13 09:06:58 +08:00
|
|
|
|
2011-04-11 06:48:51 +08:00
|
|
|
found_damage:
|
2008-02-13 09:06:58 +08:00
|
|
|
ALLOC_GROW(dir.files, dir.nr + 1, dir.alloc);
|
|
|
|
dir.files[dir.nr].name = name;
|
|
|
|
dir.files[dir.nr].changed = damage;
|
|
|
|
changed += damage;
|
|
|
|
dir.nr++;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* This can happen even with many files, if everything was renames */
|
|
|
|
if (!changed)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Show all directories with more than x% of the changes */
|
2016-09-29 23:27:31 +08:00
|
|
|
QSORT(dir.files, dir.nr, dirstat_compare);
|
2010-05-26 15:23:54 +08:00
|
|
|
gather_dirstat(options, &dir, changed, "", 0);
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
}
|
|
|
|
|
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 17:36:21 +08:00
|
|
|
static void show_dirstat_by_line(struct diffstat_t *data, struct diff_options *options)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long changed;
|
|
|
|
struct dirstat_dir dir;
|
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dir.files = NULL;
|
|
|
|
dir.alloc = 0;
|
|
|
|
dir.nr = 0;
|
|
|
|
dir.permille = options->dirstat_permille;
|
2017-11-01 02:19:11 +08:00
|
|
|
dir.cumulative = options->flags.dirstat_cumulative;
|
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 17:36:21 +08:00
|
|
|
|
|
|
|
changed = 0;
|
|
|
|
for (i = 0; i < data->nr; i++) {
|
|
|
|
struct diffstat_file *file = data->files[i];
|
|
|
|
unsigned long damage = file->added + file->deleted;
|
|
|
|
if (file->is_binary)
|
|
|
|
/*
|
|
|
|
* binary files counts bytes, not lines. Must find some
|
|
|
|
* way to normalize binary bytes vs. textual lines.
|
|
|
|
* The following heuristic assumes that there are 64
|
|
|
|
* bytes per "line".
|
|
|
|
* This is stupid and ugly, but very cheap...
|
|
|
|
*/
|
2017-07-08 18:35:35 +08:00
|
|
|
damage = DIV_ROUND_UP(damage, 64);
|
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 17:36:21 +08:00
|
|
|
ALLOC_GROW(dir.files, dir.nr + 1, dir.alloc);
|
|
|
|
dir.files[dir.nr].name = file->name;
|
|
|
|
dir.files[dir.nr].changed = damage;
|
|
|
|
changed += damage;
|
|
|
|
dir.nr++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This can happen even with many files, if everything was renames */
|
|
|
|
if (!changed)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Show all directories with more than x% of the changes */
|
2016-09-29 23:27:31 +08:00
|
|
|
QSORT(dir.files, dir.nr, dirstat_compare);
|
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 17:36:21 +08:00
|
|
|
gather_dirstat(options, &dir, changed, "", 0);
|
|
|
|
}
|
|
|
|
|
2020-08-20 08:41:32 +08:00
|
|
|
static void free_diffstat_file(struct diffstat_file *f)
|
|
|
|
{
|
|
|
|
free(f->print_name);
|
|
|
|
free(f->name);
|
|
|
|
free(f->from_name);
|
|
|
|
free(f);
|
|
|
|
}
|
|
|
|
|
2019-11-13 20:40:58 +08:00
|
|
|
void free_diffstat_info(struct diffstat_t *diffstat)
|
2007-12-12 15:46:30 +08:00
|
|
|
{
|
|
|
|
int i;
|
2020-08-20 08:41:32 +08:00
|
|
|
for (i = 0; i < diffstat->nr; i++)
|
|
|
|
free_diffstat_file(diffstat->files[i]);
|
2007-12-12 15:46:30 +08:00
|
|
|
free(diffstat->files);
|
|
|
|
}
|
|
|
|
|
2006-05-21 05:43:13 +08:00
|
|
|
struct checkdiff_t {
|
|
|
|
const char *filename;
|
2008-06-27 06:36:34 +08:00
|
|
|
int lineno;
|
2010-03-25 10:21:32 +08:00
|
|
|
int conflict_marker_size;
|
2008-06-27 06:36:34 +08:00
|
|
|
struct diff_options *o;
|
2007-12-06 16:14:14 +08:00
|
|
|
unsigned ws_rule;
|
2007-12-14 04:24:52 +08:00
|
|
|
unsigned status;
|
2006-05-21 05:43:13 +08:00
|
|
|
};
|
|
|
|
|
2010-03-25 10:21:32 +08:00
|
|
|
static int is_conflict_marker(const char *line, int marker_size, unsigned long len)
|
2008-06-27 06:37:21 +08:00
|
|
|
{
|
|
|
|
char firstchar;
|
|
|
|
int cnt;
|
|
|
|
|
2010-03-25 10:21:32 +08:00
|
|
|
if (len < marker_size + 1)
|
2008-06-27 06:37:21 +08:00
|
|
|
return 0;
|
|
|
|
firstchar = line[0];
|
|
|
|
switch (firstchar) {
|
2010-03-25 10:21:32 +08:00
|
|
|
case '=': case '>': case '<': case '|':
|
2008-06-27 06:37:21 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
2010-03-25 10:21:32 +08:00
|
|
|
for (cnt = 1; cnt < marker_size; cnt++)
|
2008-06-27 06:37:21 +08:00
|
|
|
if (line[cnt] != firstchar)
|
|
|
|
return 0;
|
2019-11-06 01:07:23 +08:00
|
|
|
/* line[1] through line[marker_size-1] are same as firstchar */
|
2010-03-25 10:21:32 +08:00
|
|
|
if (len < marker_size + 1 || !isspace(line[marker_size]))
|
2008-06-27 06:37:21 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-11-02 14:39:03 +08:00
|
|
|
static void checkdiff_consume_hunk(void *priv,
|
|
|
|
long ob, long on, long nb, long nn,
|
|
|
|
const char *func, long funclen)
|
|
|
|
|
|
|
|
{
|
|
|
|
struct checkdiff_t *data = priv;
|
|
|
|
data->lineno = nb - 1;
|
|
|
|
}
|
|
|
|
|
2021-04-13 01:15:24 +08:00
|
|
|
static int checkdiff_consume(void *priv, char *line, unsigned long len)
|
2006-05-21 05:43:13 +08:00
|
|
|
{
|
|
|
|
struct checkdiff_t *data = priv;
|
2010-03-25 10:21:32 +08:00
|
|
|
int marker_size = data->conflict_marker_size;
|
2011-08-18 13:03:12 +08:00
|
|
|
const char *ws = diff_get_color(data->o->use_color, DIFF_WHITESPACE);
|
|
|
|
const char *reset = diff_get_color(data->o->use_color, DIFF_RESET);
|
|
|
|
const char *set = diff_get_color(data->o->use_color, DIFF_FILE_NEW);
|
2007-12-13 21:32:29 +08:00
|
|
|
char *err;
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix;
|
2010-05-26 15:23:54 +08:00
|
|
|
|
|
|
|
assert(data->o);
|
2013-02-08 04:15:27 +08:00
|
|
|
line_prefix = diff_line_prefix(data->o);
|
2006-05-21 05:43:13 +08:00
|
|
|
|
|
|
|
if (line[0] == '+') {
|
2008-06-27 04:16:33 +08:00
|
|
|
unsigned bad;
|
2008-02-16 12:30:05 +08:00
|
|
|
data->lineno++;
|
2010-03-25 10:21:32 +08:00
|
|
|
if (is_conflict_marker(line + 1, marker_size, len - 1)) {
|
2008-06-27 06:37:21 +08:00
|
|
|
data->status |= 1;
|
|
|
|
fprintf(data->o->file,
|
2010-05-26 15:23:54 +08:00
|
|
|
"%s%s:%d: leftover conflict marker\n",
|
|
|
|
line_prefix, data->filename, data->lineno);
|
2008-06-27 06:37:21 +08:00
|
|
|
}
|
2008-06-27 06:35:21 +08:00
|
|
|
bad = ws_check(line + 1, len - 1, data->ws_rule);
|
2008-06-27 04:16:33 +08:00
|
|
|
if (!bad)
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2008-06-27 04:16:33 +08:00
|
|
|
data->status |= bad;
|
|
|
|
err = whitespace_error_string(bad);
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(data->o->file, "%s%s:%d: %s.\n",
|
|
|
|
line_prefix, data->filename, data->lineno, err);
|
2007-12-13 21:32:29 +08:00
|
|
|
free(err);
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line(data->o, set, reset, line, 1);
|
2008-06-27 06:35:21 +08:00
|
|
|
ws_check_emit(line + 1, len - 1, data->ws_rule,
|
2008-06-27 06:36:34 +08:00
|
|
|
data->o->file, set, reset, ws);
|
2008-06-27 06:36:59 +08:00
|
|
|
} else if (line[0] == ' ') {
|
2006-05-21 05:43:13 +08:00
|
|
|
data->lineno++;
|
|
|
|
}
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2006-05-05 17:41:53 +08:00
|
|
|
static unsigned char *deflate_it(char *data,
|
|
|
|
unsigned long size,
|
|
|
|
unsigned long *result_size)
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
{
|
2006-05-05 17:41:53 +08:00
|
|
|
int bound;
|
|
|
|
unsigned char *deflated;
|
2011-06-11 02:52:15 +08:00
|
|
|
git_zstream stream;
|
2006-05-05 17:41:53 +08:00
|
|
|
|
2011-06-11 01:55:10 +08:00
|
|
|
git_deflate_init(&stream, zlib_compression_level);
|
2011-06-11 02:18:17 +08:00
|
|
|
bound = git_deflate_bound(&stream, size);
|
2006-05-05 17:41:53 +08:00
|
|
|
deflated = xmalloc(bound);
|
|
|
|
stream.next_out = deflated;
|
|
|
|
stream.avail_out = bound;
|
|
|
|
|
|
|
|
stream.next_in = (unsigned char *)data;
|
|
|
|
stream.avail_in = size;
|
2011-06-11 01:55:10 +08:00
|
|
|
while (git_deflate(&stream, Z_FINISH) == Z_OK)
|
2006-05-05 17:41:53 +08:00
|
|
|
; /* nothing */
|
2011-06-11 01:55:10 +08:00
|
|
|
git_deflate_end(&stream);
|
2006-05-05 17:41:53 +08:00
|
|
|
*result_size = stream.total_out;
|
|
|
|
return deflated;
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:01 +08:00
|
|
|
static void emit_binary_diff_body(struct diff_options *o,
|
|
|
|
mmfile_t *one, mmfile_t *two)
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
{
|
2006-05-05 17:41:53 +08:00
|
|
|
void *cp;
|
|
|
|
void *delta;
|
|
|
|
void *deflated;
|
|
|
|
void *data;
|
|
|
|
unsigned long orig_size;
|
|
|
|
unsigned long delta_size;
|
|
|
|
unsigned long deflate_size;
|
|
|
|
unsigned long data_size;
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
|
2006-05-05 17:41:53 +08:00
|
|
|
/* We could do deflated delta, or we could do just deflated two,
|
|
|
|
* whichever is smaller.
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
*/
|
2006-05-05 17:41:53 +08:00
|
|
|
delta = NULL;
|
|
|
|
deflated = deflate_it(two->ptr, two->size, &deflate_size);
|
|
|
|
if (one->size && two->size) {
|
|
|
|
delta = diff_delta(one->ptr, one->size,
|
|
|
|
two->ptr, two->size,
|
|
|
|
&delta_size, deflate_size);
|
|
|
|
if (delta) {
|
|
|
|
void *to_free = delta;
|
|
|
|
orig_size = delta_size;
|
|
|
|
delta = deflate_it(delta, delta_size, &delta_size);
|
|
|
|
free(to_free);
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-05-05 17:41:53 +08:00
|
|
|
if (delta && delta_size < deflate_size) {
|
2018-11-11 15:05:04 +08:00
|
|
|
char *s = xstrfmt("%"PRIuMAX , (uintmax_t)orig_size);
|
2017-06-30 08:07:01 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_DIFF_HEADER_DELTA,
|
|
|
|
s, strlen(s), 0);
|
|
|
|
free(s);
|
2006-05-05 17:41:53 +08:00
|
|
|
free(deflated);
|
|
|
|
data = delta;
|
|
|
|
data_size = delta_size;
|
2017-06-30 08:07:01 +08:00
|
|
|
} else {
|
|
|
|
char *s = xstrfmt("%lu", two->size);
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_DIFF_HEADER_LITERAL,
|
|
|
|
s, strlen(s), 0);
|
|
|
|
free(s);
|
2006-05-05 17:41:53 +08:00
|
|
|
free(delta);
|
|
|
|
data = deflated;
|
|
|
|
data_size = deflate_size;
|
|
|
|
}
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
|
2006-05-05 17:41:53 +08:00
|
|
|
/* emit data encoded in base85 */
|
|
|
|
cp = data;
|
|
|
|
while (data_size) {
|
2017-06-30 08:07:01 +08:00
|
|
|
int len;
|
2006-05-05 17:41:53 +08:00
|
|
|
int bytes = (52 < data_size) ? 52 : data_size;
|
2017-06-30 08:07:01 +08:00
|
|
|
char line[71];
|
2006-05-05 17:41:53 +08:00
|
|
|
data_size -= bytes;
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
if (bytes <= 26)
|
|
|
|
line[0] = bytes + 'A' - 1;
|
|
|
|
else
|
|
|
|
line[0] = bytes - 26 + 'a' - 1;
|
|
|
|
encode_85(line + 1, cp, bytes);
|
2006-06-18 23:18:09 +08:00
|
|
|
cp = (char *) cp + bytes;
|
2017-06-30 08:07:01 +08:00
|
|
|
|
|
|
|
len = strlen(line);
|
|
|
|
line[len++] = '\n';
|
|
|
|
line[len] = '\0';
|
|
|
|
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_DIFF_BODY,
|
|
|
|
line, len, 0);
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
}
|
2017-06-30 08:07:01 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_DIFF_FOOTER, NULL, 0, 0);
|
2006-05-05 17:41:53 +08:00
|
|
|
free(data);
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:01 +08:00
|
|
|
static void emit_binary_diff(struct diff_options *o,
|
|
|
|
mmfile_t *one, mmfile_t *two)
|
2006-08-17 07:08:14 +08:00
|
|
|
{
|
2017-06-30 08:07:01 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_DIFF_HEADER, NULL, 0, 0);
|
|
|
|
emit_binary_diff_body(o, one, two);
|
|
|
|
emit_binary_diff_body(o, two, one);
|
2006-08-17 07:08:14 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
int diff_filespec_is_binary(struct repository *r,
|
|
|
|
struct diff_filespec *one)
|
2007-07-06 15:18:54 +08:00
|
|
|
{
|
2020-04-08 06:11:41 +08:00
|
|
|
struct diff_populate_filespec_options dpf_options = {
|
|
|
|
.check_binary = 1,
|
|
|
|
};
|
|
|
|
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 05:43:36 +08:00
|
|
|
if (one->is_binary == -1) {
|
2018-09-21 23:57:33 +08:00
|
|
|
diff_filespec_load_driver(one, r->index);
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 05:43:36 +08:00
|
|
|
if (one->driver->binary != -1)
|
|
|
|
one->is_binary = one->driver->binary;
|
|
|
|
else {
|
|
|
|
if (!one->data && DIFF_FILE_VALID(one))
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(r, one, &dpf_options);
|
2014-08-16 11:08:05 +08:00
|
|
|
if (one->is_binary == -1 && one->data)
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 05:43:36 +08:00
|
|
|
one->is_binary = buffer_is_binary(one->data,
|
|
|
|
one->size);
|
|
|
|
if (one->is_binary == -1)
|
|
|
|
one->is_binary = 0;
|
|
|
|
}
|
|
|
|
}
|
2007-07-06 15:18:54 +08:00
|
|
|
return one->is_binary;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:33 +08:00
|
|
|
static const struct userdiff_funcname *
|
|
|
|
diff_funcname_pattern(struct diff_options *o, struct diff_filespec *one)
|
2007-07-06 15:45:10 +08:00
|
|
|
{
|
2018-09-21 23:57:33 +08:00
|
|
|
diff_filespec_load_driver(one, o->repo->index);
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 05:43:36 +08:00
|
|
|
return one->driver->funcname.pattern ? &one->driver->funcname : NULL;
|
2007-07-06 15:45:10 +08:00
|
|
|
}
|
|
|
|
|
2008-08-19 11:08:09 +08:00
|
|
|
void diff_set_mnemonic_prefix(struct diff_options *options, const char *a, const char *b)
|
|
|
|
{
|
|
|
|
if (!options->a_prefix)
|
|
|
|
options->a_prefix = a;
|
|
|
|
if (!options->b_prefix)
|
|
|
|
options->b_prefix = b;
|
|
|
|
}
|
|
|
|
|
2018-11-10 13:49:06 +08:00
|
|
|
struct userdiff_driver *get_textconv(struct repository *r,
|
2018-09-21 23:57:33 +08:00
|
|
|
struct diff_filespec *one)
|
refactor userdiff textconv code
The original implementation of textconv put the conversion
into fill_mmfile. This was a bad idea for a number of
reasons:
- it made the semantics of fill_mmfile unclear. In some
cases, it was allocating data (if a text conversion
occurred), and in some cases not (if we could use the
data directly from the filespec). But the caller had
no idea which had happened, and so didn't know whether
the memory should be freed
- similarly, the caller had no idea if a text conversion
had occurred, and so didn't know whether the contents
should be treated as binary or not. This meant that we
incorrectly guessed that text-converted content was
binary and didn't actually show it (unless the user
overrode us with "diff.foo.binary = false", which then
created problems in plumbing where the text conversion
did _not_ occur)
- not all callers of fill_mmfile want the text contents. In
particular, we don't really want diffstat, whitespace
checks, patch id generation, etc, to look at the
converted contents.
This patch pulls the conversion code directly into
builtin_diff, so that we only see the conversion when
generating an actual patch. We also then know whether we are
doing a conversion, so we can check the binary-ness and free
the data from the mmfile appropriately (the previous version
leaked quite badly when text conversion was used)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26 12:44:53 +08:00
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one))
|
|
|
|
return NULL;
|
2010-09-22 05:01:24 +08:00
|
|
|
|
2018-11-10 13:49:06 +08:00
|
|
|
diff_filespec_load_driver(one, r->index);
|
|
|
|
return userdiff_get_textconv(r, one->driver);
|
refactor userdiff textconv code
The original implementation of textconv put the conversion
into fill_mmfile. This was a bad idea for a number of
reasons:
- it made the semantics of fill_mmfile unclear. In some
cases, it was allocating data (if a text conversion
occurred), and in some cases not (if we could use the
data directly from the filespec). But the caller had
no idea which had happened, and so didn't know whether
the memory should be freed
- similarly, the caller had no idea if a text conversion
had occurred, and so didn't know whether the contents
should be treated as binary or not. This meant that we
incorrectly guessed that text-converted content was
binary and didn't actually show it (unless the user
overrode us with "diff.foo.binary = false", which then
created problems in plumbing where the text conversion
did _not_ occur)
- not all callers of fill_mmfile want the text contents. In
particular, we don't really want diffstat, whitespace
checks, patch id generation, etc, to look at the
converted contents.
This patch pulls the conversion code directly into
builtin_diff, so that we only see the conversion when
generating an actual patch. We also then know whether we are
doing a conversion, so we can check the binary-ness and free
the data from the mmfile appropriately (the previous version
leaked quite badly when text conversion was used)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26 12:44:53 +08:00
|
|
|
}
|
|
|
|
|
2022-02-02 10:37:34 +08:00
|
|
|
static struct strbuf *additional_headers(struct diff_options *o,
|
|
|
|
const char *path)
|
|
|
|
{
|
|
|
|
if (!o->additional_path_headers)
|
|
|
|
return NULL;
|
|
|
|
return strmap_get(o->additional_path_headers, path);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_formatted_headers(struct strbuf *msg,
|
|
|
|
struct strbuf *more_headers,
|
|
|
|
const char *line_prefix,
|
|
|
|
const char *meta,
|
|
|
|
const char *reset)
|
|
|
|
{
|
|
|
|
char *next, *newline;
|
|
|
|
|
|
|
|
for (next = more_headers->buf; *next; next = newline) {
|
|
|
|
newline = strchrnul(next, '\n');
|
|
|
|
strbuf_addf(msg, "%s%s%.*s%s\n", line_prefix, meta,
|
|
|
|
(int)(newline - next), next, reset);
|
|
|
|
if (*newline)
|
|
|
|
newline++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static void builtin_diff(const char *name_a,
|
|
|
|
const char *name_b,
|
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
|
|
|
const char *xfrm_msg,
|
2010-05-26 10:50:12 +08:00
|
|
|
int must_show_header,
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
struct diff_options *o,
|
2006-04-22 14:57:45 +08:00
|
|
|
int complete_rewrite)
|
|
|
|
{
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
const char *lbl[2];
|
|
|
|
char *a_one, *b_two;
|
2012-11-13 23:42:46 +08:00
|
|
|
const char *meta = diff_get_color_opt(o, DIFF_METAINFO);
|
2007-11-11 03:05:14 +08:00
|
|
|
const char *reset = diff_get_color_opt(o, DIFF_RESET);
|
2008-08-19 11:08:09 +08:00
|
|
|
const char *a_prefix, *b_prefix;
|
2010-04-02 08:12:15 +08:00
|
|
|
struct userdiff_driver *textconv_one = NULL;
|
|
|
|
struct userdiff_driver *textconv_two = NULL;
|
2009-11-20 05:12:24 +08:00
|
|
|
struct strbuf header = STRBUF_INIT;
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix = diff_line_prefix(o);
|
2008-08-19 11:08:09 +08:00
|
|
|
|
2016-09-01 07:27:25 +08:00
|
|
|
diff_set_mnemonic_prefix(o, "a/", "b/");
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.reverse_diff) {
|
2016-09-01 07:27:25 +08:00
|
|
|
a_prefix = o->b_prefix;
|
|
|
|
b_prefix = o->a_prefix;
|
|
|
|
} else {
|
|
|
|
a_prefix = o->a_prefix;
|
|
|
|
b_prefix = o->b_prefix;
|
|
|
|
}
|
|
|
|
|
2016-09-01 07:27:21 +08:00
|
|
|
if (o->submodule_format == DIFF_SUBMODULE_LOG &&
|
|
|
|
(!one->mode || S_ISGITLINK(one->mode)) &&
|
|
|
|
(!two->mode || S_ISGITLINK(two->mode))) {
|
2020-08-13 03:44:02 +08:00
|
|
|
show_submodule_diff_summary(o, one->path ? one->path : two->path,
|
2016-09-01 07:27:23 +08:00
|
|
|
&one->oid, &two->oid,
|
2017-06-30 08:07:00 +08:00
|
|
|
two->dirty_submodule);
|
2009-10-19 20:38:32 +08:00
|
|
|
return;
|
2016-09-01 07:27:25 +08:00
|
|
|
} else if (o->submodule_format == DIFF_SUBMODULE_INLINE_DIFF &&
|
|
|
|
(!one->mode || S_ISGITLINK(one->mode)) &&
|
|
|
|
(!two->mode || S_ISGITLINK(two->mode))) {
|
2017-06-30 08:07:00 +08:00
|
|
|
show_submodule_inline_diff(o, one->path ? one->path : two->path,
|
2016-09-01 07:27:25 +08:00
|
|
|
&one->oid, &two->oid,
|
2017-06-30 08:07:00 +08:00
|
|
|
two->dirty_submodule);
|
2016-09-01 07:27:25 +08:00
|
|
|
return;
|
2009-10-19 20:38:32 +08:00
|
|
|
}
|
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.allow_textconv) {
|
2018-11-10 13:49:06 +08:00
|
|
|
textconv_one = get_textconv(o->repo, one);
|
|
|
|
textconv_two = get_textconv(o->repo, two);
|
2008-12-09 16:13:21 +08:00
|
|
|
}
|
|
|
|
|
fix bogus "diff --git" header from "diff --no-index"
When "git diff --no-index" is given an absolute pathname, it
would generate a diff header with the absolute path
prepended by the prefix, like:
diff --git a/dev/null b/foo
Not only is this nonsensical, and not only does it violate
the description of diffs given in git-diff(1), but it would
produce broken binary diffs. Unlike text diffs, the binary
diffs don't contain the filenames anywhere else, and so "git
apply" relies on this header to figure out the filename.
This patch just refuses to use an invalid name for anything
visible in the diff.
Now, this fixes the "git diff --no-index --binary a
/dev/null" kind of case (and we'll end up using "a" as the
basename), but some other insane cases are impossible to
handle. If you do
git diff --no-index --binary a /bin/echo
you'll still get a patch like
diff --git a/a b/bin/echo
old mode 100644
new mode 100755
index ...
and "git apply" will refuse to apply it for a couple of
reasons, and the diff is simply bogus.
And that, btw, is no longer a bug, I think. It's impossible
to know whethe the user meant for the patch to be a rename
or not. And as such, refusing to apply it because you don't
know what name you should use is probably _exactly_ the
right thing to do!
Original problem reported by Imre Deak. Test script and problem
description by Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 03:35:15 +08:00
|
|
|
/* Never use a non-valid filename anywhere if at all possible */
|
|
|
|
name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
|
|
|
|
name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
|
|
|
|
|
2008-08-19 11:08:09 +08:00
|
|
|
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
|
|
|
|
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
|
2006-04-22 14:57:45 +08:00
|
|
|
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
|
|
|
|
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
|
2022-02-02 10:37:34 +08:00
|
|
|
if (!DIFF_FILE_VALID(one) && !DIFF_FILE_VALID(two)) {
|
|
|
|
/*
|
|
|
|
* We should only reach this point for pairs from
|
|
|
|
* create_filepairs_for_header_only_notifications(). For
|
|
|
|
* these, we should avoid the "/dev/null" special casing
|
|
|
|
* above, meaning we avoid showing such pairs as either
|
|
|
|
* "new file" or "deleted file" below.
|
|
|
|
*/
|
|
|
|
lbl[0] = a_one;
|
|
|
|
lbl[1] = b_two;
|
|
|
|
}
|
2012-11-13 23:42:46 +08:00
|
|
|
strbuf_addf(&header, "%s%sdiff --git %s %s%s\n", line_prefix, meta, a_one, b_two, reset);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (lbl[0][0] == '/') {
|
|
|
|
/* /dev/null */
|
2012-11-13 23:42:46 +08:00
|
|
|
strbuf_addf(&header, "%s%snew file mode %06o%s\n", line_prefix, meta, two->mode, reset);
|
2010-05-04 06:38:07 +08:00
|
|
|
if (xfrm_msg)
|
|
|
|
strbuf_addstr(&header, xfrm_msg);
|
2010-05-26 10:50:12 +08:00
|
|
|
must_show_header = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else if (lbl[1][0] == '/') {
|
2012-11-13 23:42:46 +08:00
|
|
|
strbuf_addf(&header, "%s%sdeleted file mode %06o%s\n", line_prefix, meta, one->mode, reset);
|
2010-05-04 06:38:07 +08:00
|
|
|
if (xfrm_msg)
|
|
|
|
strbuf_addstr(&header, xfrm_msg);
|
2010-05-26 10:50:12 +08:00
|
|
|
must_show_header = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (one->mode != two->mode) {
|
2012-11-13 23:42:46 +08:00
|
|
|
strbuf_addf(&header, "%s%sold mode %06o%s\n", line_prefix, meta, one->mode, reset);
|
|
|
|
strbuf_addf(&header, "%s%snew mode %06o%s\n", line_prefix, meta, two->mode, reset);
|
2010-05-26 10:50:12 +08:00
|
|
|
must_show_header = 1;
|
2006-06-14 00:45:44 +08:00
|
|
|
}
|
2010-05-04 06:38:07 +08:00
|
|
|
if (xfrm_msg)
|
|
|
|
strbuf_addstr(&header, xfrm_msg);
|
2009-11-20 05:12:24 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* we do not run diff between different kind
|
|
|
|
* of objects.
|
|
|
|
*/
|
|
|
|
if ((one->mode ^ two->mode) & S_IFMT)
|
|
|
|
goto free_ab_and_return;
|
2008-12-09 16:12:28 +08:00
|
|
|
if (complete_rewrite &&
|
2018-09-21 23:57:19 +08:00
|
|
|
(textconv_one || !diff_filespec_is_binary(o->repo, one)) &&
|
|
|
|
(textconv_two || !diff_filespec_is_binary(o->repo, two))) {
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
header.buf, header.len, 0);
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_reset(&header);
|
2008-12-09 16:13:21 +08:00
|
|
|
emit_rewrite_diff(name_a, name_b, one, two,
|
2018-09-21 23:57:19 +08:00
|
|
|
textconv_one, textconv_two, o);
|
2007-02-26 06:34:54 +08:00
|
|
|
o->found_changes = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
goto free_ab_and_return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-01 08:11:55 +08:00
|
|
|
if (o->irreversible_delete && lbl[1][0] == '/') {
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER, header.buf,
|
|
|
|
header.len, 0);
|
2011-03-01 08:11:55 +08:00
|
|
|
strbuf_reset(&header);
|
|
|
|
goto free_ab_and_return;
|
2017-11-01 02:19:11 +08:00
|
|
|
} else if (!o->flags.text &&
|
2018-09-21 23:57:19 +08:00
|
|
|
( (!textconv_one && diff_filespec_is_binary(o->repo, one)) ||
|
|
|
|
(!textconv_two && diff_filespec_is_binary(o->repo, two)) )) {
|
2017-06-30 08:06:58 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2014-08-16 11:08:06 +08:00
|
|
|
if (!one->data && !two->data &&
|
|
|
|
S_ISREG(one->mode) && S_ISREG(two->mode) &&
|
2017-11-01 02:19:11 +08:00
|
|
|
!o->flags.binary) {
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (oideq(&one->oid, &two->oid)) {
|
2014-08-16 11:08:06 +08:00
|
|
|
if (must_show_header)
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
header.buf, header.len,
|
|
|
|
0);
|
2014-08-16 11:08:06 +08:00
|
|
|
goto free_ab_and_return;
|
|
|
|
}
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
header.buf, header.len, 0);
|
2017-06-30 08:06:58 +08:00
|
|
|
strbuf_addf(&sb, "%sBinary files %s and %s differ\n",
|
|
|
|
diff_line_prefix(o), lbl[0], lbl[1]);
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_FILES,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_release(&sb);
|
2014-08-16 11:08:06 +08:00
|
|
|
goto free_ab_and_return;
|
|
|
|
}
|
2018-09-21 23:57:19 +08:00
|
|
|
if (fill_mmfile(o->repo, &mf1, one) < 0 ||
|
|
|
|
fill_mmfile(o->repo, &mf2, two) < 0)
|
diff: avoid useless filespec population
builtin_diff calls fill_mmfile fairly early, which in turn
calls diff_populate_filespec, which actually retrieves the
file's blob contents into a buffer. Long ago, this was
sensible as we would need to look at the blobs eventually.
These days, however, we may not ever want those blobs if we
end up using a textconv cache, and for large binary files
(exactly the sort for which you might have a textconv
cache), just retrieving the objects can be costly.
This patch just pushes the fill_mmfile call a bit later, so
we can avoid populating the filespec in some cases. There
is one thing to note that looks like a bug but isn't. We
push the fill_mmfile down into the first branch of a
conditional. It seems like we would need it on the other
branch, too, but we don't; fill_textconv does it for us (in
fact, before this, we were just writing over the results of
the fill_mmfile on that branch).
Here's a timing sample on a commit with 45 changed jpgs and
avis. The result is fully textconv cached, but we still
wasted a lot of time just pulling the blobs from storage.
The total size of the blobs (source and dest) is about
180M.
[before]
$ time git show >/dev/null
real 0m0.352s
user 0m0.148s
sys 0m0.200s
[after]
$ time git show >/dev/null
real 0m0.009s
user 0m0.004s
sys 0m0.004s
And that's on a warm cache. On a cold cache, the "after"
case is not much worse, but the "before" case has to do an
extra 180M of I/O.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-02 08:14:24 +08:00
|
|
|
die("unable to read files to diff");
|
2006-05-05 17:41:53 +08:00
|
|
|
/* Quite common confusing case */
|
|
|
|
if (mf1.size == mf2.size &&
|
2010-05-26 10:50:12 +08:00
|
|
|
!memcmp(mf1.ptr, mf2.ptr, mf1.size)) {
|
|
|
|
if (must_show_header)
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
header.buf, header.len, 0);
|
2006-05-05 17:41:53 +08:00
|
|
|
goto free_ab_and_return;
|
2010-05-26 10:50:12 +08:00
|
|
|
}
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER, header.buf, header.len, 0);
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_reset(&header);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.binary)
|
2017-06-30 08:07:01 +08:00
|
|
|
emit_binary_diff(o, &mf1, &mf2);
|
2017-06-30 08:06:58 +08:00
|
|
|
else {
|
|
|
|
strbuf_addf(&sb, "%sBinary files %s and %s differ\n",
|
|
|
|
diff_line_prefix(o), lbl[0], lbl[1]);
|
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_BINARY_FILES,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
2007-02-26 06:34:54 +08:00
|
|
|
o->found_changes = 1;
|
2011-03-01 08:11:55 +08:00
|
|
|
} else {
|
2006-04-22 14:57:45 +08:00
|
|
|
/* Crazy xdl interfaces.. */
|
2019-01-12 06:17:22 +08:00
|
|
|
const char *diffopts;
|
use skip_prefix to avoid magic numbers
It's a common idiom to match a prefix and then skip past it
with a magic number, like:
if (starts_with(foo, "bar"))
foo += 3;
This is easy to get wrong, since you have to count the
prefix string yourself, and there's no compiler check if the
string changes. We can use skip_prefix to avoid the magic
numbers here.
Note that some of these conversions could be much shorter.
For example:
if (starts_with(arg, "--foo=")) {
bar = arg + 6;
continue;
}
could become:
if (skip_prefix(arg, "--foo=", &bar))
continue;
However, I have left it as:
if (skip_prefix(arg, "--foo=", &v)) {
bar = v;
continue;
}
to visually match nearby cases which need to actually
process the string. Like:
if (skip_prefix(arg, "--foo=", &v)) {
bar = atoi(v);
continue;
}
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19 03:47:50 +08:00
|
|
|
const char *v;
|
2006-04-22 14:57:45 +08:00
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
struct emit_callback ecbdata;
|
2008-10-06 05:43:21 +08:00
|
|
|
const struct userdiff_funcname *pe;
|
2007-07-06 15:45:10 +08:00
|
|
|
|
diff -p: squelch "diff --git" header for stat-dirty paths
The plumbing "diff" commands look at the working tree files without
refreshing the index themselves for performance reasons (the calling
script is expected to do that upfront just once, before calling one or
more of them). In the early days of git, they showed the "diff --git"
header before they actually ask the xdiff machinery to produce patches,
and ended up showing only these headers if the real contents are the same
and the difference they noticed was only because the stat info cached in
the index did not match that of the working tree. It was too late for the
implementation to take the header that it already emitted back.
But 3e97c7c (No diff -b/-w output for all-whitespace changes, 2009-11-19)
introduced necessary logic to keep the meta-information headers in a
strbuf and delay their output until the xdiff machinery noticed actual
changes. This was primarily in order to generate patches that ignore
whitespaces. When operating under "-w" mode, we wouldn't know if the
header is needed until we actually look at the resulting patch, so it was
a sensible thing to do, but we did not realize that the same reasoning
applies to stat-dirty paths.
Later, 296c6bb (diff: fix "git show -C -C" output when renaming a binary
file, 2010-05-26) generalized this machinery and added must_show_header
toggle. This is turned on when the header must be shown even when there
is no patch to be produced, e.g. only the mode was changed, or the path
was renamed, without changing the contents. However, when it did so, it
still kept the special case for the "-w" mode, which meant that the
plumbing would keep showing these phantom changes.
This corrects this historical inconsistency by allowing the plumbing to
omit paths that are only stat-dirty from its output in the same way as it
handles whitespace only changes under "-w" option.
The change in the behaviour can be seen in the updated test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01 10:14:16 +08:00
|
|
|
if (must_show_header) {
|
2017-06-30 08:06:57 +08:00
|
|
|
emit_diff_symbol(o, DIFF_SYMBOL_HEADER,
|
|
|
|
header.buf, header.len, 0);
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_reset(&header);
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:22 +08:00
|
|
|
mf1.size = fill_textconv(o->repo, textconv_one, one, &mf1.ptr);
|
|
|
|
mf2.size = fill_textconv(o->repo, textconv_two, two, &mf2.ptr);
|
refactor userdiff textconv code
The original implementation of textconv put the conversion
into fill_mmfile. This was a bad idea for a number of
reasons:
- it made the semantics of fill_mmfile unclear. In some
cases, it was allocating data (if a text conversion
occurred), and in some cases not (if we could use the
data directly from the filespec). But the caller had
no idea which had happened, and so didn't know whether
the memory should be freed
- similarly, the caller had no idea if a text conversion
had occurred, and so didn't know whether the contents
should be treated as binary or not. This meant that we
incorrectly guessed that text-converted content was
binary and didn't actually show it (unless the user
overrode us with "diff.foo.binary = false", which then
created problems in plumbing where the text conversion
did _not_ occur)
- not all callers of fill_mmfile want the text contents. In
particular, we don't really want diffstat, whitespace
checks, patch id generation, etc, to look at the
converted contents.
This patch pulls the conversion code directly into
builtin_diff, so that we only see the conversion when
generating an actual patch. We also then know whether we are
doing a conversion, so we can check the binary-ness and free
the data from the mmfile appropriately (the previous version
leaked quite badly when text conversion was used)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26 12:44:53 +08:00
|
|
|
|
2018-09-21 23:57:33 +08:00
|
|
|
pe = diff_funcname_pattern(o, one);
|
2008-09-19 06:40:48 +08:00
|
|
|
if (!pe)
|
2018-09-21 23:57:33 +08:00
|
|
|
pe = diff_funcname_pattern(o, two);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2008-10-25 21:30:37 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-14 00:45:44 +08:00
|
|
|
memset(&ecbdata, 0, sizeof(ecbdata));
|
2018-08-13 19:33:11 +08:00
|
|
|
if (o->flags.suppress_diff_headers)
|
|
|
|
lbl[0] = NULL;
|
2006-04-22 14:57:45 +08:00
|
|
|
ecbdata.label_path = lbl;
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 13:04:23 +08:00
|
|
|
ecbdata.color_diff = want_color(o->use_color);
|
2018-09-21 23:57:37 +08:00
|
|
|
ecbdata.ws_rule = whitespace_rule(o->repo->index, name_b);
|
2009-09-04 15:41:15 +08:00
|
|
|
if (ecbdata.ws_rule & WS_BLANK_AT_EOF)
|
2009-09-15 13:05:57 +08:00
|
|
|
check_blank_at_eof(&mf1, &mf2, &ecbdata);
|
2010-05-26 15:08:02 +08:00
|
|
|
ecbdata.opt = o;
|
2018-08-13 19:33:11 +08:00
|
|
|
if (header.len && !o->flags.suppress_diff_headers)
|
|
|
|
ecbdata.header = &header;
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = o->xdl_opts;
|
2020-10-20 14:48:09 +08:00
|
|
|
xpp.ignore_regex = o->ignore_regex;
|
|
|
|
xpp.ignore_regex_nr = o->ignore_regex_nr;
|
2017-11-28 03:47:47 +08:00
|
|
|
xpp.anchors = o->anchors;
|
|
|
|
xpp.anchors_nr = o->anchors_nr;
|
2006-05-14 04:23:48 +08:00
|
|
|
xecfg.ctxlen = o->context;
|
2008-12-29 02:45:32 +08:00
|
|
|
xecfg.interhunkctxlen = o->interhunkcontext;
|
2006-04-22 14:57:45 +08:00
|
|
|
xecfg.flags = XDL_EMIT_FUNCNAMES;
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.funccontext)
|
2011-10-09 19:36:57 +08:00
|
|
|
xecfg.flags |= XDL_EMIT_FUNCCONTEXT;
|
2008-09-19 06:40:48 +08:00
|
|
|
if (pe)
|
2008-09-19 06:42:48 +08:00
|
|
|
xdiff_set_find_func(&xecfg, pe->pattern, pe->cflags);
|
2019-01-12 06:17:22 +08:00
|
|
|
|
|
|
|
diffopts = getenv("GIT_DIFF_OPTS");
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!diffopts)
|
|
|
|
;
|
use skip_prefix to avoid magic numbers
It's a common idiom to match a prefix and then skip past it
with a magic number, like:
if (starts_with(foo, "bar"))
foo += 3;
This is easy to get wrong, since you have to count the
prefix string yourself, and there's no compiler check if the
string changes. We can use skip_prefix to avoid the magic
numbers here.
Note that some of these conversions could be much shorter.
For example:
if (starts_with(arg, "--foo=")) {
bar = arg + 6;
continue;
}
could become:
if (skip_prefix(arg, "--foo=", &bar))
continue;
However, I have left it as:
if (skip_prefix(arg, "--foo=", &v)) {
bar = v;
continue;
}
to visually match nearby cases which need to actually
process the string. Like:
if (skip_prefix(arg, "--foo=", &v)) {
bar = atoi(v);
continue;
}
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19 03:47:50 +08:00
|
|
|
else if (skip_prefix(diffopts, "--unified=", &v))
|
|
|
|
xecfg.ctxlen = strtoul(v, NULL, 10);
|
|
|
|
else if (skip_prefix(diffopts, "-u", &v))
|
|
|
|
xecfg.ctxlen = strtoul(v, NULL, 10);
|
2019-01-12 06:17:22 +08:00
|
|
|
|
2012-03-15 02:24:08 +08:00
|
|
|
if (o->word_diff)
|
|
|
|
init_diff_words_data(&ecbdata, o, one, two);
|
2018-11-02 14:35:45 +08:00
|
|
|
if (xdi_diff_outf(&mf1, &mf2, NULL, fn_out_consume,
|
|
|
|
&ecbdata, &xpp, &xecfg))
|
react to errors in xdi_diff
When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).
In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.
Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.
We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).
There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 07:12:23 +08:00
|
|
|
die("unable to generate diff for %s", one->path);
|
2010-04-14 23:59:06 +08:00
|
|
|
if (o->word_diff)
|
2006-07-29 05:56:15 +08:00
|
|
|
free_diff_words_data(&ecbdata);
|
refactor userdiff textconv code
The original implementation of textconv put the conversion
into fill_mmfile. This was a bad idea for a number of
reasons:
- it made the semantics of fill_mmfile unclear. In some
cases, it was allocating data (if a text conversion
occurred), and in some cases not (if we could use the
data directly from the filespec). But the caller had
no idea which had happened, and so didn't know whether
the memory should be freed
- similarly, the caller had no idea if a text conversion
had occurred, and so didn't know whether the contents
should be treated as binary or not. This meant that we
incorrectly guessed that text-converted content was
binary and didn't actually show it (unless the user
overrode us with "diff.foo.binary = false", which then
created problems in plumbing where the text conversion
did _not_ occur)
- not all callers of fill_mmfile want the text contents. In
particular, we don't really want diffstat, whitespace
checks, patch id generation, etc, to look at the
converted contents.
This patch pulls the conversion code directly into
builtin_diff, so that we only see the conversion when
generating an actual patch. We also then know whether we are
doing a conversion, so we can check the binary-ness and free
the data from the mmfile appropriately (the previous version
leaked quite badly when text conversion was used)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26 12:44:53 +08:00
|
|
|
if (textconv_one)
|
|
|
|
free(mf1.ptr);
|
|
|
|
if (textconv_two)
|
|
|
|
free(mf2.ptr);
|
2009-07-02 06:01:43 +08:00
|
|
|
xdiff_clear_find_func(&xecfg);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
free_ab_and_return:
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_release(&header);
|
2007-05-04 04:05:48 +08:00
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2006-04-22 14:57:45 +08:00
|
|
|
free(a_one);
|
|
|
|
free(b_two);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-02-24 22:09:59 +08:00
|
|
|
static char *get_compact_summary(const struct diff_filepair *p, int is_renamed)
|
|
|
|
{
|
|
|
|
if (!is_renamed) {
|
|
|
|
if (p->status == DIFF_STATUS_ADDED) {
|
|
|
|
if (S_ISLNK(p->two->mode))
|
|
|
|
return "new +l";
|
|
|
|
else if ((p->two->mode & 0777) == 0755)
|
|
|
|
return "new +x";
|
|
|
|
else
|
|
|
|
return "new";
|
|
|
|
} else if (p->status == DIFF_STATUS_DELETED)
|
|
|
|
return "gone";
|
|
|
|
}
|
|
|
|
if (S_ISLNK(p->one->mode) && !S_ISLNK(p->two->mode))
|
|
|
|
return "mode -l";
|
|
|
|
else if (!S_ISLNK(p->one->mode) && S_ISLNK(p->two->mode))
|
|
|
|
return "mode +l";
|
|
|
|
else if ((p->one->mode & 0777) == 0644 &&
|
|
|
|
(p->two->mode & 0777) == 0755)
|
|
|
|
return "mode +x";
|
|
|
|
else if ((p->one->mode & 0777) == 0755 &&
|
|
|
|
(p->two->mode & 0777) == 0644)
|
|
|
|
return "mode -x";
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static void builtin_diffstat(const char *name_a, const char *name_b,
|
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
2006-04-26 14:40:09 +08:00
|
|
|
struct diffstat_t *diffstat,
|
2006-06-14 23:40:23 +08:00
|
|
|
struct diff_options *o,
|
Fix "git diff --stat" for interesting - but empty - file changes
The behavior of "git diff --stat" is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.
Which means that the stat output will simply not show files that only
had "other" changes: they were created or deleted, or their mode was
changed.
Now, those changes do show up in the summary, but so do renames, so
the diffstat logic is inconsistent. Why does it show renames with zero
lines changed, but not mode changes or added files with zero lines
changed?
So change the logic to not check for "is_renamed", but for
"is_interesting" instead, where "interesting" is judged to be any
action but a pure data change (because a pure data change with zero
data changed really isn't worth showing, if we ever get one in our
diffpairs).
So if you did
chmod +x Makefile
git diff --stat
before, it would show empty (" 0 files changed"), with this it shows
Makefile | 0
1 file changed, 0 insertions(+), 0 deletions(-)
which I think is a more correct diffstat (and then with "--summary" it
shows *what* the metadata change to Makefile was - this is completely
consistent with our handling of renamed files).
Side note: the old behavior was *really* odd. With no changes at all,
"git diff --stat" output was empty. With just a chmod, it said "0
files changed". No way is our legacy behavior sane.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18 01:00:37 +08:00
|
|
|
struct diff_filepair *p)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
struct diffstat_file *data;
|
2020-09-24 15:41:41 +08:00
|
|
|
int may_differ;
|
Fix "git diff --stat" for interesting - but empty - file changes
The behavior of "git diff --stat" is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.
Which means that the stat output will simply not show files that only
had "other" changes: they were created or deleted, or their mode was
changed.
Now, those changes do show up in the summary, but so do renames, so
the diffstat logic is inconsistent. Why does it show renames with zero
lines changed, but not mode changes or added files with zero lines
changed?
So change the logic to not check for "is_renamed", but for
"is_interesting" instead, where "interesting" is judged to be any
action but a pure data change (because a pure data change with zero
data changed really isn't worth showing, if we ever get one in our
diffpairs).
So if you did
chmod +x Makefile
git diff --stat
before, it would show empty (" 0 files changed"), with this it shows
Makefile | 0
1 file changed, 0 insertions(+), 0 deletions(-)
which I think is a more correct diffstat (and then with "--summary" it
shows *what* the metadata change to Makefile was - this is completely
consistent with our handling of renamed files).
Side note: the old behavior was *really* odd. With no changes at all,
"git diff --stat" output was empty. With just a chmod, it said "0
files changed". No way is our legacy behavior sane.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18 01:00:37 +08:00
|
|
|
int complete_rewrite = 0;
|
|
|
|
|
|
|
|
if (!DIFF_PAIR_UNMERGED(p)) {
|
|
|
|
if (p->status == DIFF_STATUS_MODIFIED && p->score)
|
|
|
|
complete_rewrite = 1;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
data = diffstat_add(diffstat, name_a, name_b);
|
2012-11-28 03:17:14 +08:00
|
|
|
data->is_interesting = p->status != DIFF_STATUS_UNKNOWN;
|
2018-02-24 22:09:59 +08:00
|
|
|
if (o->flags.stat_with_summary)
|
|
|
|
data->comments = get_compact_summary(p, data->is_renamed);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (!one || !two) {
|
|
|
|
data->is_unmerged = 1;
|
|
|
|
return;
|
|
|
|
}
|
2011-02-19 16:04:56 +08:00
|
|
|
|
2020-09-24 15:41:41 +08:00
|
|
|
/* saves some reads if true, not a guarantee of diff outcome */
|
|
|
|
may_differ = !(one->oid_valid && two->oid_valid &&
|
|
|
|
oideq(&one->oid, &two->oid));
|
2012-05-02 01:10:15 +08:00
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (diff_filespec_is_binary(o->repo, one) ||
|
|
|
|
diff_filespec_is_binary(o->repo, two)) {
|
2011-02-19 16:04:56 +08:00
|
|
|
data->is_binary = 1;
|
2020-09-24 15:41:41 +08:00
|
|
|
if (!may_differ) {
|
2012-05-02 01:10:14 +08:00
|
|
|
data->added = 0;
|
|
|
|
data->deleted = 0;
|
|
|
|
} else {
|
2018-09-21 23:57:19 +08:00
|
|
|
data->added = diff_filespec_size(o->repo, two);
|
|
|
|
data->deleted = diff_filespec_size(o->repo, one);
|
2012-05-02 01:10:14 +08:00
|
|
|
}
|
2011-02-19 16:04:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
else if (complete_rewrite) {
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(o->repo, one, NULL);
|
|
|
|
diff_populate_filespec(o->repo, two, NULL);
|
2006-04-26 14:40:09 +08:00
|
|
|
data->deleted = count_lines(one->data, one->size);
|
|
|
|
data->added = count_lines(two->data, two->size);
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2020-09-24 15:41:41 +08:00
|
|
|
else if (may_differ) {
|
2006-04-22 14:57:45 +08:00
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (fill_mmfile(o->repo, &mf1, one) < 0 ||
|
|
|
|
fill_mmfile(o->repo, &mf2, two) < 0)
|
2011-02-19 16:04:56 +08:00
|
|
|
die("unable to read files to diff");
|
|
|
|
|
2008-10-25 21:30:37 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = o->xdl_opts;
|
2020-10-20 14:48:09 +08:00
|
|
|
xpp.ignore_regex = o->ignore_regex;
|
|
|
|
xpp.ignore_regex_nr = o->ignore_regex_nr;
|
2017-11-28 03:47:47 +08:00
|
|
|
xpp.anchors = o->anchors;
|
|
|
|
xpp.anchors_nr = o->anchors_nr;
|
2011-09-23 01:54:47 +08:00
|
|
|
xecfg.ctxlen = o->context;
|
|
|
|
xecfg.interhunkctxlen = o->interhunkcontext;
|
2021-04-13 01:15:29 +08:00
|
|
|
xecfg.flags = XDL_EMIT_NO_HUNK_HDR;
|
|
|
|
if (xdi_diff_outf(&mf1, &mf2, NULL,
|
2018-11-02 14:36:06 +08:00
|
|
|
diffstat_consume, diffstat, &xpp, &xecfg))
|
react to errors in xdi_diff
When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).
In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.
Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.
We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).
There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 07:12:23 +08:00
|
|
|
die("unable to generate diffstat for %s", one->path);
|
2020-08-20 08:41:32 +08:00
|
|
|
|
|
|
|
if (DIFF_FILE_VALID(one) && DIFF_FILE_VALID(two)) {
|
|
|
|
struct diffstat_file *file =
|
|
|
|
diffstat->files[diffstat->nr - 1];
|
|
|
|
/*
|
|
|
|
* Omit diffstats of modified files where nothing changed.
|
2020-09-24 15:41:41 +08:00
|
|
|
* Even if may_differ, this might be the case due to
|
2020-08-20 08:41:32 +08:00
|
|
|
* ignoring whitespace changes, etc.
|
|
|
|
*
|
|
|
|
* But note that we special-case additions, deletions,
|
|
|
|
* renames, and mode changes as adding an empty file,
|
|
|
|
* for example is still of interest.
|
|
|
|
*/
|
|
|
|
if ((p->status == DIFF_STATUS_MODIFIED)
|
|
|
|
&& !file->added
|
|
|
|
&& !file->deleted
|
|
|
|
&& one->mode == two->mode) {
|
|
|
|
free_diffstat_file(file);
|
|
|
|
diffstat->nr--;
|
|
|
|
}
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2007-05-04 04:05:48 +08:00
|
|
|
|
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-05-21 05:43:13 +08:00
|
|
|
static void builtin_checkdiff(const char *name_a, const char *name_b,
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
const char *attr_path,
|
2008-06-27 06:34:54 +08:00
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
|
|
|
struct diff_options *o)
|
2006-05-21 05:43:13 +08:00
|
|
|
{
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
struct checkdiff_t data;
|
|
|
|
|
|
|
|
if (!two)
|
|
|
|
return;
|
|
|
|
|
|
|
|
memset(&data, 0, sizeof(data));
|
|
|
|
data.filename = name_b ? name_b : name_a;
|
|
|
|
data.lineno = 0;
|
2008-06-27 06:36:34 +08:00
|
|
|
data.o = o;
|
2018-09-21 23:57:37 +08:00
|
|
|
data.ws_rule = whitespace_rule(o->repo->index, attr_path);
|
2018-09-21 23:57:27 +08:00
|
|
|
data.conflict_marker_size = ll_merge_marker_size(o->repo->index, attr_path);
|
2006-05-21 05:43:13 +08:00
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (fill_mmfile(o->repo, &mf1, one) < 0 ||
|
|
|
|
fill_mmfile(o->repo, &mf2, two) < 0)
|
2006-05-21 05:43:13 +08:00
|
|
|
die("unable to read files to diff");
|
|
|
|
|
2008-06-27 06:34:54 +08:00
|
|
|
/*
|
|
|
|
* All the other codepaths check both sides, but not checking
|
|
|
|
* the "old" side here is deliberate. We are checking the newly
|
|
|
|
* introduced changes, and as long as the "new" side is text, we
|
|
|
|
* can and should check what it introduces.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
if (diff_filespec_is_binary(o->repo, two))
|
2007-05-04 04:05:48 +08:00
|
|
|
goto free_and_return;
|
2006-05-21 05:43:13 +08:00
|
|
|
else {
|
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
|
2008-10-25 21:30:37 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2008-08-21 02:47:55 +08:00
|
|
|
xecfg.ctxlen = 1; /* at least one context line */
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = 0;
|
2018-11-02 14:39:03 +08:00
|
|
|
if (xdi_diff_outf(&mf1, &mf2, checkdiff_consume_hunk,
|
|
|
|
checkdiff_consume, &data,
|
react to errors in xdi_diff
When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).
In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.
Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.
We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).
There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 07:12:23 +08:00
|
|
|
&xpp, &xecfg))
|
|
|
|
die("unable to generate checkdiff for %s", one->path);
|
2008-06-27 06:36:59 +08:00
|
|
|
|
2009-09-04 14:39:43 +08:00
|
|
|
if (data.ws_rule & WS_BLANK_AT_EOF) {
|
2009-09-15 13:05:57 +08:00
|
|
|
struct emit_callback ecbdata;
|
|
|
|
int blank_at_eof;
|
|
|
|
|
|
|
|
ecbdata.ws_rule = data.ws_rule;
|
|
|
|
check_blank_at_eof(&mf1, &mf2, &ecbdata);
|
2010-10-11 01:24:06 +08:00
|
|
|
blank_at_eof = ecbdata.blank_at_eof_in_postimage;
|
2009-09-15 13:05:57 +08:00
|
|
|
|
2009-09-04 14:39:43 +08:00
|
|
|
if (blank_at_eof) {
|
|
|
|
static char *err;
|
|
|
|
if (!err)
|
|
|
|
err = whitespace_error_string(WS_BLANK_AT_EOF);
|
|
|
|
fprintf(o->file, "%s:%d: %s.\n",
|
|
|
|
data.filename, blank_at_eof, err);
|
|
|
|
data.status = 1; /* report errors */
|
|
|
|
}
|
2008-06-27 06:36:59 +08:00
|
|
|
}
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
2007-05-04 04:05:48 +08:00
|
|
|
free_and_return:
|
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2007-12-14 04:24:52 +08:00
|
|
|
if (data.status)
|
2017-11-01 02:19:11 +08:00
|
|
|
o->flags.check_failed = 1;
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diff_filespec *alloc_filespec(const char *path)
|
|
|
|
{
|
2016-02-23 06:44:32 +08:00
|
|
|
struct diff_filespec *spec;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2016-02-23 06:44:32 +08:00
|
|
|
FLEXPTR_ALLOC_STR(spec, path, path);
|
2007-10-26 02:19:10 +08:00
|
|
|
spec->count = 1;
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 05:43:36 +08:00
|
|
|
spec->is_binary = -1;
|
2006-04-22 14:57:45 +08:00
|
|
|
return spec;
|
|
|
|
}
|
|
|
|
|
2007-10-26 02:19:10 +08:00
|
|
|
void free_filespec(struct diff_filespec *spec)
|
|
|
|
{
|
|
|
|
if (!--spec->count) {
|
|
|
|
diff_free_filespec_data(spec);
|
|
|
|
free(spec);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-31 01:30:50 +08:00
|
|
|
void fill_filespec(struct diff_filespec *spec, const struct object_id *oid,
|
|
|
|
int oid_valid, unsigned short mode)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
if (mode) {
|
|
|
|
spec->mode = canon_mode(mode);
|
2017-05-31 01:30:50 +08:00
|
|
|
oidcpy(&spec->oid, oid);
|
|
|
|
spec->oid_valid = oid_valid;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2007-05-26 06:37:40 +08:00
|
|
|
* Given a name and sha1 pair, if the index tells us the file in
|
2006-04-22 14:57:45 +08:00
|
|
|
* the work tree has that object contents, return true, so that
|
|
|
|
* prepare_temp_file() does not have to inflate and extract.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
static int reuse_worktree_file(struct index_state *istate,
|
|
|
|
const char *name,
|
|
|
|
const struct object_id *oid,
|
|
|
|
int want_file)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
|
|
|
const struct cache_entry *ce;
|
2006-04-22 14:57:45 +08:00
|
|
|
struct stat st;
|
|
|
|
int pos, len;
|
|
|
|
|
2009-03-23 06:26:07 +08:00
|
|
|
/*
|
|
|
|
* We do not read the cache ourselves here, because the
|
2006-04-22 14:57:45 +08:00
|
|
|
* benchmark with my previous version that always reads cache
|
|
|
|
* shows that it makes things worse for diff-tree comparing
|
|
|
|
* two linux-2.6 kernel trees in an already checked out work
|
|
|
|
* tree. This is because most diff-tree comparisons deal with
|
|
|
|
* only a small number of files, while reading the cache is
|
|
|
|
* expensive for a large project, and its cost outweighs the
|
|
|
|
* savings we get by not inflating the object to a temporary
|
|
|
|
* file. Practically, this code only helps when we are used
|
|
|
|
* by diff-cache --cached, which does read the cache before
|
|
|
|
* calling us.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
if (!istate->cache)
|
2006-04-22 14:57:45 +08:00
|
|
|
return 0;
|
|
|
|
|
2006-12-14 19:15:57 +08:00
|
|
|
/* We want to avoid the working directory if our caller
|
|
|
|
* doesn't need the data in a normal file, this system
|
|
|
|
* is rather slow with its stat/open/mmap/close syscalls,
|
|
|
|
* and the object is contained in a pack file. The pack
|
|
|
|
* is probably already open and will be faster to obtain
|
|
|
|
* the data through than the working directory. Loose
|
|
|
|
* objects however would tend to be slower as they need
|
|
|
|
* to be individually opened and inflated.
|
|
|
|
*/
|
2018-05-02 08:25:33 +08:00
|
|
|
if (!FAST_WORKING_DIRECTORY && !want_file && has_object_pack(oid))
|
2006-12-14 19:15:57 +08:00
|
|
|
return 0;
|
|
|
|
|
diff: do not reuse worktree files that need "clean" conversion
When accessing a blob for a diff, we may try to reuse file
contents in the working tree, under the theory that it is
faster to mmap those file contents than it would be to
extract the content from the object database.
When we have to filter those contents, though, that
assumption does not hold. Even for our internal conversions
like CRLF, we have to allocate and fill a new buffer anyway.
But much worse, for external clean filters we have to exec
an arbitrary script, and we have no idea how expensive it
may be to run.
So let's skip this optimization when conversion into git's
"clean" form is required. This applies whenever the
"want_file" flag is false. When it's true, the caller
actually wants the smudged worktree contents, which the
reused file by definition already has (in fact, this is a
key optimization going the other direction, since reusing
the worktree file there lets us skip smudge filters).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22 23:27:53 +08:00
|
|
|
/*
|
|
|
|
* Similarly, if we'd have to convert the file contents anyway, that
|
|
|
|
* makes the optimization not worthwhile.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
if (!want_file && would_convert_to_git(istate, name))
|
diff: do not reuse worktree files that need "clean" conversion
When accessing a blob for a diff, we may try to reuse file
contents in the working tree, under the theory that it is
faster to mmap those file contents than it would be to
extract the content from the object database.
When we have to filter those contents, though, that
assumption does not hold. Even for our internal conversions
like CRLF, we have to allocate and fill a new buffer anyway.
But much worse, for external clean filters we have to exec
an arbitrary script, and we have no idea how expensive it
may be to run.
So let's skip this optimization when conversion into git's
"clean" form is required. This applies whenever the
"want_file" flag is false. When it's true, the caller
actually wants the smudged worktree contents, which the
reused file by definition already has (in fact, this is a
key optimization going the other direction, since reusing
the worktree file there lets us skip smudge filters).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22 23:27:53 +08:00
|
|
|
return 0;
|
|
|
|
|
2021-09-08 19:23:56 +08:00
|
|
|
/*
|
|
|
|
* If this path does not match our sparse-checkout definition,
|
|
|
|
* then the file will not be in the working directory.
|
|
|
|
*/
|
|
|
|
if (!path_in_sparse_checkout(name, istate))
|
|
|
|
return 0;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
len = strlen(name);
|
2018-09-21 23:57:19 +08:00
|
|
|
pos = index_name_pos(istate, name, len);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (pos < 0)
|
|
|
|
return 0;
|
2018-09-21 23:57:19 +08:00
|
|
|
ce = istate->cache[pos];
|
2008-01-19 15:45:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is not the sha1 we are looking for, or
|
|
|
|
* unreusable because it is not a regular file.
|
|
|
|
*/
|
2018-08-29 05:22:48 +08:00
|
|
|
if (!oideq(oid, &ce->oid) || !S_ISREG(ce->ce_mode))
|
2006-04-22 14:57:45 +08:00
|
|
|
return 0;
|
2008-01-19 15:45:24 +08:00
|
|
|
|
2009-03-23 06:26:07 +08:00
|
|
|
/*
|
|
|
|
* If ce is marked as "assume unchanged", there is no
|
|
|
|
* guarantee that work tree matches what we are looking for.
|
|
|
|
*/
|
2009-08-20 21:46:58 +08:00
|
|
|
if ((ce->ce_flags & CE_VALID) || ce_skip_worktree(ce))
|
2009-03-23 06:26:07 +08:00
|
|
|
return 0;
|
|
|
|
|
2008-01-19 15:45:24 +08:00
|
|
|
/*
|
|
|
|
* If ce matches the file in the work tree, we can reuse it.
|
2006-04-22 14:57:45 +08:00
|
|
|
*/
|
2008-01-19 15:45:24 +08:00
|
|
|
if (ce_uptodate(ce) ||
|
2018-09-21 23:57:19 +08:00
|
|
|
(!lstat(name, &st) && !ie_match_stat(istate, ce, &st, 0)))
|
2008-01-19 15:45:24 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
Expose subprojects as special files to "git diff" machinery
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16 02:14:28 +08:00
|
|
|
static int diff_populate_gitlink(struct diff_filespec *s, int size_only)
|
|
|
|
{
|
2016-02-23 06:45:08 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
char *dirty = "";
|
2010-01-17 01:42:53 +08:00
|
|
|
|
|
|
|
/* Are we looking at the work tree? */
|
2010-03-13 05:23:52 +08:00
|
|
|
if (s->dirty_submodule)
|
2010-01-17 01:42:53 +08:00
|
|
|
dirty = "-dirty";
|
|
|
|
|
2016-06-25 07:09:23 +08:00
|
|
|
strbuf_addf(&buf, "Subproject commit %s%s\n",
|
|
|
|
oid_to_hex(&s->oid), dirty);
|
2016-02-23 06:45:08 +08:00
|
|
|
s->size = buf.len;
|
Expose subprojects as special files to "git diff" machinery
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16 02:14:28 +08:00
|
|
|
if (size_only) {
|
|
|
|
s->data = NULL;
|
2016-02-23 06:45:08 +08:00
|
|
|
strbuf_release(&buf);
|
|
|
|
} else {
|
|
|
|
s->data = strbuf_detach(&buf, NULL);
|
|
|
|
s->should_free = 1;
|
Expose subprojects as special files to "git diff" machinery
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16 02:14:28 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* While doing rename detection and pickaxe operation, we may need to
|
|
|
|
* grab the data for the blob (or file) for our own in-core comparison.
|
|
|
|
* diff_filespec has data and size fields for this purpose.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
int diff_populate_filespec(struct repository *r,
|
|
|
|
struct diff_filespec *s,
|
2020-04-08 06:11:41 +08:00
|
|
|
const struct diff_populate_filespec_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2020-04-08 06:11:41 +08:00
|
|
|
int size_only = options ? options->check_size_only : 0;
|
|
|
|
int check_binary = options ? options->check_binary : 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
int err = 0;
|
2018-01-14 06:49:31 +08:00
|
|
|
int conv_flags = global_conv_flags_eol;
|
2013-06-25 05:35:04 +08:00
|
|
|
/*
|
|
|
|
* demote FAIL to WARN to allow inspecting the situation
|
|
|
|
* instead of refusing.
|
|
|
|
*/
|
2018-01-14 06:49:31 +08:00
|
|
|
if (conv_flags & CONV_EOL_RNDTRP_DIE)
|
|
|
|
conv_flags = CONV_EOL_RNDTRP_WARN;
|
2013-06-25 05:35:04 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!DIFF_FILE_VALID(s))
|
|
|
|
die("internal error: asking to populate invalid file.");
|
|
|
|
if (S_ISDIR(s->mode))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (s->data)
|
2007-05-04 04:05:48 +08:00
|
|
|
return 0;
|
Expose subprojects as special files to "git diff" machinery
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16 02:14:28 +08:00
|
|
|
|
2007-05-07 16:14:21 +08:00
|
|
|
if (size_only && 0 < s->size)
|
|
|
|
return 0;
|
|
|
|
|
2007-05-22 04:08:28 +08:00
|
|
|
if (S_ISGITLINK(s->mode))
|
Expose subprojects as special files to "git diff" machinery
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16 02:14:28 +08:00
|
|
|
return diff_populate_gitlink(s, size_only);
|
|
|
|
|
2016-06-25 07:09:24 +08:00
|
|
|
if (!s->oid_valid ||
|
2018-09-21 23:57:19 +08:00
|
|
|
reuse_worktree_file(r->index, s->path, &s->oid, 0)) {
|
2008-10-10 03:12:12 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2006-04-22 14:57:45 +08:00
|
|
|
struct stat st;
|
|
|
|
int fd;
|
Lazy man's auto-CRLF
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 03:07:23 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (lstat(s->path, &st) < 0) {
|
2017-10-27 17:33:25 +08:00
|
|
|
err_empty:
|
|
|
|
err = -1;
|
|
|
|
empty:
|
|
|
|
s->data = (char *)"";
|
|
|
|
s->size = 0;
|
|
|
|
return err;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2007-03-07 09:44:37 +08:00
|
|
|
s->size = xsize_t(st.st_size);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!s->size)
|
|
|
|
goto empty;
|
|
|
|
if (S_ISLNK(st.st_mode)) {
|
2008-12-18 02:26:13 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
if (strbuf_readlink(&sb, s->path, s->size))
|
2006-04-22 14:57:45 +08:00
|
|
|
goto err_empty;
|
2008-12-19 00:56:51 +08:00
|
|
|
s->size = sb.len;
|
|
|
|
s->data = strbuf_detach(&sb, NULL);
|
2008-12-18 02:26:13 +08:00
|
|
|
s->should_free = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2017-03-02 01:04:44 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Even if the caller would be happy with getting
|
|
|
|
* only the size, we cannot return early at this
|
|
|
|
* point if the path requires us to run the content
|
|
|
|
* conversion.
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
if (size_only && !would_convert_to_git(r->index, s->path))
|
2008-12-18 02:26:13 +08:00
|
|
|
return 0;
|
2017-03-02 01:04:44 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: this check uses xsize_t(st.st_size) that may
|
|
|
|
* not be the true size of the blob after it goes
|
|
|
|
* through convert_to_git(). This may not strictly be
|
|
|
|
* correct, but the whole point of big_file_threshold
|
|
|
|
* and is_binary check being that we want to avoid
|
|
|
|
* opening the file and inspecting the contents, this
|
|
|
|
* is probably fine.
|
|
|
|
*/
|
2020-04-08 06:11:41 +08:00
|
|
|
if (check_binary &&
|
2014-08-16 11:08:05 +08:00
|
|
|
s->size > big_file_threshold && s->is_binary == -1) {
|
|
|
|
s->is_binary = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
fd = open(s->path, O_RDONLY);
|
|
|
|
if (fd < 0)
|
|
|
|
goto err_empty;
|
2006-12-24 13:47:23 +08:00
|
|
|
s->data = xmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
|
2006-04-22 14:57:45 +08:00
|
|
|
close(fd);
|
|
|
|
s->should_munmap = 1;
|
Lazy man's auto-CRLF
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 03:07:23 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert from working tree format to canonical git format
|
|
|
|
*/
|
2018-09-21 23:57:19 +08:00
|
|
|
if (convert_to_git(r->index, s->path, s->data, s->size, &buf, conv_flags)) {
|
2007-10-21 17:23:49 +08:00
|
|
|
size_t size = 0;
|
Lazy man's auto-CRLF
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 03:07:23 +08:00
|
|
|
munmap(s->data, s->size);
|
|
|
|
s->should_munmap = 0;
|
2007-10-21 17:23:49 +08:00
|
|
|
s->data = strbuf_detach(&buf, &size);
|
|
|
|
s->size = size;
|
Lazy man's auto-CRLF
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 03:07:23 +08:00
|
|
|
s->should_free = 1;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else {
|
2020-04-08 06:11:42 +08:00
|
|
|
struct object_info info = {
|
|
|
|
.sizep = &s->size
|
|
|
|
};
|
|
|
|
|
|
|
|
if (!(size_only || check_binary))
|
|
|
|
/*
|
|
|
|
* Set contentp, since there is no chance that merely
|
|
|
|
* the size is sufficient.
|
|
|
|
*/
|
|
|
|
info.contentp = &s->data;
|
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
if (options && options->missing_object_cb) {
|
|
|
|
if (!oid_object_info_extended(r, &s->oid, &info,
|
|
|
|
OBJECT_INFO_LOOKUP_REPLACE |
|
|
|
|
OBJECT_INFO_SKIP_FETCH_OBJECT))
|
|
|
|
goto object_read;
|
|
|
|
options->missing_object_cb(options->missing_object_data);
|
|
|
|
}
|
2020-04-08 06:11:42 +08:00
|
|
|
if (oid_object_info_extended(r, &s->oid, &info,
|
|
|
|
OBJECT_INFO_LOOKUP_REPLACE))
|
|
|
|
die("unable to read %s", oid_to_hex(&s->oid));
|
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
object_read:
|
2020-04-08 06:11:41 +08:00
|
|
|
if (size_only || check_binary) {
|
2014-08-16 11:08:05 +08:00
|
|
|
if (size_only)
|
|
|
|
return 0;
|
|
|
|
if (s->size > big_file_threshold && s->is_binary == -1) {
|
|
|
|
s->is_binary = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2020-04-08 06:11:42 +08:00
|
|
|
if (!info.contentp) {
|
|
|
|
info.contentp = &s->data;
|
|
|
|
if (oid_object_info_extended(r, &s->oid, &info,
|
|
|
|
OBJECT_INFO_LOOKUP_REPLACE))
|
|
|
|
die("unable to read %s", oid_to_hex(&s->oid));
|
|
|
|
}
|
2014-08-16 11:08:05 +08:00
|
|
|
s->should_free = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-03 12:01:03 +08:00
|
|
|
void diff_free_filespec_blob(struct diff_filespec *s)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
if (s->should_free)
|
|
|
|
free(s->data);
|
|
|
|
else if (s->should_munmap)
|
|
|
|
munmap(s->data, s->size);
|
2007-05-04 04:05:48 +08:00
|
|
|
|
|
|
|
if (s->should_free || s->should_munmap) {
|
|
|
|
s->should_free = s->should_munmap = 0;
|
|
|
|
s->data = NULL;
|
|
|
|
}
|
2007-09-26 03:29:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_free_filespec_data(struct diff_filespec *s)
|
|
|
|
{
|
2020-11-07 01:14:52 +08:00
|
|
|
if (!s)
|
|
|
|
return;
|
|
|
|
|
2007-10-03 12:01:03 +08:00
|
|
|
diff_free_filespec_blob(s);
|
2017-06-16 07:15:46 +08:00
|
|
|
FREE_AND_NULL(s->cnt_data);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static void prep_temp_blob(struct index_state *istate,
|
|
|
|
const char *path, struct diff_tempfile *temp,
|
2006-04-22 14:57:45 +08:00
|
|
|
void *blob,
|
|
|
|
unsigned long size,
|
2016-06-25 07:09:29 +08:00
|
|
|
const struct object_id *oid,
|
2006-04-22 14:57:45 +08:00
|
|
|
int mode)
|
|
|
|
{
|
2009-03-21 19:42:52 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2009-05-31 16:35:52 +08:00
|
|
|
char *path_dup = xstrdup(path);
|
|
|
|
const char *base = basename(path_dup);
|
2020-03-17 02:05:03 +08:00
|
|
|
struct checkout_metadata meta;
|
|
|
|
|
|
|
|
init_checkout_metadata(&meta, NULL, NULL, oid);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2022-04-21 04:30:10 +08:00
|
|
|
temp->tempfile = mks_tempfile_dt("git-blob-XXXXXX", base);
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
if (!temp->tempfile)
|
2009-06-27 23:58:46 +08:00
|
|
|
die_errno("unable to create temp-file");
|
2018-09-21 23:57:19 +08:00
|
|
|
if (convert_to_working_tree(istate, path,
|
2020-03-17 02:05:03 +08:00
|
|
|
(const char *)blob, (size_t)size, &buf, &meta)) {
|
2009-03-21 19:42:52 +08:00
|
|
|
blob = buf.buf;
|
|
|
|
size = buf.len;
|
|
|
|
}
|
2017-09-25 14:24:06 +08:00
|
|
|
if (write_in_full(temp->tempfile->fd, blob, size) < 0 ||
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
close_tempfile_gently(temp->tempfile))
|
2009-06-27 23:58:47 +08:00
|
|
|
die_errno("unable to write temp-file");
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
temp->name = get_tempfile_path(temp->tempfile);
|
2016-06-25 07:09:29 +08:00
|
|
|
oid_to_hex_r(temp->hex, oid);
|
2015-09-25 05:06:08 +08:00
|
|
|
xsnprintf(temp->mode, sizeof(temp->mode), "%06o", mode);
|
2009-03-21 19:42:52 +08:00
|
|
|
strbuf_release(&buf);
|
2009-05-31 16:35:52 +08:00
|
|
|
free(path_dup);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static struct diff_tempfile *prepare_temp_file(struct repository *r,
|
|
|
|
const char *name,
|
|
|
|
struct diff_filespec *one)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
struct diff_tempfile *temp = claim_diff_tempfile();
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!DIFF_FILE_VALID(one)) {
|
|
|
|
not_a_valid_file:
|
|
|
|
/* A '-' entry produces this for file-2, and
|
|
|
|
* a '+' entry produces this for file-1.
|
|
|
|
*/
|
|
|
|
temp->name = "/dev/null";
|
2015-09-25 05:06:08 +08:00
|
|
|
xsnprintf(temp->hex, sizeof(temp->hex), ".");
|
|
|
|
xsnprintf(temp->mode, sizeof(temp->mode), ".");
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
return temp;
|
|
|
|
}
|
|
|
|
|
2014-02-17 00:52:34 +08:00
|
|
|
if (!S_ISGITLINK(one->mode) &&
|
2016-06-25 07:09:24 +08:00
|
|
|
(!one->oid_valid ||
|
2018-09-21 23:57:19 +08:00
|
|
|
reuse_worktree_file(r->index, name, &one->oid, 1))) {
|
2006-04-22 14:57:45 +08:00
|
|
|
struct stat st;
|
|
|
|
if (lstat(name, &st) < 0) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
goto not_a_valid_file;
|
2009-06-27 23:58:46 +08:00
|
|
|
die_errno("stat(%s)", name);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
if (S_ISLNK(st.st_mode)) {
|
2009-05-25 18:46:09 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
if (strbuf_readlink(&sb, name, st.st_size) < 0)
|
2009-06-27 23:58:47 +08:00
|
|
|
die_errno("readlink(%s)", name);
|
2018-09-21 23:57:19 +08:00
|
|
|
prep_temp_blob(r->index, name, temp, sb.buf, sb.len,
|
2016-06-25 07:09:24 +08:00
|
|
|
(one->oid_valid ?
|
2021-04-26 09:02:56 +08:00
|
|
|
&one->oid : null_oid()),
|
2016-06-25 07:09:24 +08:00
|
|
|
(one->oid_valid ?
|
2006-04-22 14:57:45 +08:00
|
|
|
one->mode : S_IFLNK));
|
2009-05-25 18:46:09 +08:00
|
|
|
strbuf_release(&sb);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* we can borrow from the file in the work tree */
|
|
|
|
temp->name = name;
|
2016-06-25 07:09:24 +08:00
|
|
|
if (!one->oid_valid)
|
2021-04-26 09:02:56 +08:00
|
|
|
oid_to_hex_r(temp->hex, null_oid());
|
2006-04-22 14:57:45 +08:00
|
|
|
else
|
2017-01-29 06:03:03 +08:00
|
|
|
oid_to_hex_r(temp->hex, &one->oid);
|
2006-04-22 14:57:45 +08:00
|
|
|
/* Even though we may sometimes borrow the
|
|
|
|
* contents from the work tree, we always want
|
|
|
|
* one->mode. mode is trustworthy even when
|
2017-05-31 01:30:52 +08:00
|
|
|
* !(one->oid_valid), as long as
|
2006-04-22 14:57:45 +08:00
|
|
|
* DIFF_FILE_VALID(one).
|
|
|
|
*/
|
2015-09-25 05:06:08 +08:00
|
|
|
xsnprintf(temp->mode, sizeof(temp->mode), "%06o", one->mode);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
return temp;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else {
|
2020-04-08 06:11:41 +08:00
|
|
|
if (diff_populate_filespec(r, one, NULL))
|
2006-04-22 14:57:45 +08:00
|
|
|
die("cannot read data blob for %s", one->path);
|
2018-09-21 23:57:19 +08:00
|
|
|
prep_temp_blob(r->index, name, temp,
|
|
|
|
one->data, one->size,
|
2016-06-25 07:09:29 +08:00
|
|
|
&one->oid, one->mode);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
return temp;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static void add_external_diff_name(struct repository *r,
|
2020-07-29 04:24:53 +08:00
|
|
|
struct strvec *argv,
|
2014-04-20 03:22:25 +08:00
|
|
|
const char *name,
|
|
|
|
struct diff_filespec *df)
|
|
|
|
{
|
2018-09-21 23:57:19 +08:00
|
|
|
struct diff_tempfile *temp = prepare_temp_file(r, name, df);
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(argv, temp->name);
|
|
|
|
strvec_push(argv, temp->hex);
|
|
|
|
strvec_push(argv, temp->mode);
|
2014-04-20 03:22:25 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/* An external diff command takes:
|
|
|
|
*
|
|
|
|
* diff-cmd name infile1 infile1-sha1 infile1-mode \
|
|
|
|
* infile2 infile2-sha1 infile2-mode [ rename-to ]
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void run_external_diff(const char *pgm,
|
|
|
|
const char *name,
|
|
|
|
const char *other,
|
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
|
|
|
const char *xfrm_msg,
|
2013-12-06 07:38:46 +08:00
|
|
|
struct diff_options *o)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2020-07-29 04:24:53 +08:00
|
|
|
struct strvec argv = STRVEC_INIT;
|
|
|
|
struct strvec env = STRVEC_INIT;
|
2013-12-06 07:38:46 +08:00
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(&argv, pgm);
|
|
|
|
strvec_push(&argv, name);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (one && two) {
|
2018-09-21 23:57:19 +08:00
|
|
|
add_external_diff_name(o->repo, &argv, name, one);
|
2014-04-20 03:22:25 +08:00
|
|
|
if (!other)
|
2018-09-21 23:57:19 +08:00
|
|
|
add_external_diff_name(o->repo, &argv, name, two);
|
2014-04-20 03:22:25 +08:00
|
|
|
else {
|
2018-09-21 23:57:19 +08:00
|
|
|
add_external_diff_name(o->repo, &argv, other, two);
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(&argv, other);
|
|
|
|
strvec_push(&argv, xfrm_msg);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
2013-12-06 07:38:46 +08:00
|
|
|
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_pushf(&env, "GIT_DIFF_PATH_COUNTER=%d", ++o->diff_path_counter);
|
|
|
|
strvec_pushf(&env, "GIT_DIFF_PATH_TOTAL=%d", q->nr);
|
2013-12-06 07:38:46 +08:00
|
|
|
|
2019-07-11 16:23:41 +08:00
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2020-07-29 08:37:20 +08:00
|
|
|
if (run_command_v_opt_cd_env(argv.v, RUN_USING_SHELL, NULL, env.v))
|
run_external_diff: clean up error handling
When the external diff reports an error, we try to clean up
and die. However, we can make this process a bit simpler:
1. We do not need to bother freeing memory, since we are
about to exit. Nor do we need to clean up our
tempfiles, since the atexit() handler will do it for
us. So we can die as soon as we see the error.
3. We can just call die() rather than fprintf/exit. This
does technically change our exit code, but the exit
code of "1" is not meaningful here. In fact, it is
probably wrong, since "1" from diff usually means
"completed successfully, but there were differences".
And while we're there, we can mark the error message for
translation, and drop the full stop at the end to make it
more like our other messages.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-20 03:19:19 +08:00
|
|
|
die(_("external diff died, stopping at %s"), name);
|
2013-12-06 07:38:46 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
remove_tempfile();
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_clear(&argv);
|
|
|
|
strvec_clear(&env);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2009-01-26 16:08:24 +08:00
|
|
|
static int similarity_index(struct diff_filepair *p)
|
|
|
|
{
|
|
|
|
return p->score * 100 / MAX_SCORE;
|
|
|
|
}
|
|
|
|
|
diff: handle sha1 abbreviations outside of repository
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20 14:21:25 +08:00
|
|
|
static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
|
|
|
|
{
|
|
|
|
if (startup_info->have_repository)
|
2018-03-12 10:27:30 +08:00
|
|
|
return find_unique_abbrev(oid, abbrev);
|
diff: handle sha1 abbreviations outside of repository
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20 14:21:25 +08:00
|
|
|
else {
|
|
|
|
char *hex = oid_to_hex(oid);
|
2016-10-28 05:58:48 +08:00
|
|
|
if (abbrev < 0)
|
|
|
|
abbrev = FALLBACK_DEFAULT_ABBREV;
|
2018-07-16 09:28:05 +08:00
|
|
|
if (abbrev > the_hash_algo->hexsz)
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("oid abbreviation out of range: %d", abbrev);
|
diff: handle --no-abbrev in no-index case
There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.
setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)
Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.
The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.
Signed-off-by: Jack Bates <jack@nottheoilrig.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-07 00:56:14 +08:00
|
|
|
if (abbrev)
|
|
|
|
hex[abbrev] = '\0';
|
diff: handle sha1 abbreviations outside of repository
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20 14:21:25 +08:00
|
|
|
return hex;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-26 16:08:24 +08:00
|
|
|
static void fill_metainfo(struct strbuf *msg,
|
|
|
|
const char *name,
|
|
|
|
const char *other,
|
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
|
|
|
struct diff_options *o,
|
2010-05-04 06:38:07 +08:00
|
|
|
struct diff_filepair *p,
|
2010-06-19 02:16:57 +08:00
|
|
|
int *must_show_header,
|
2010-05-04 06:38:07 +08:00
|
|
|
int use_color)
|
2009-01-26 16:08:24 +08:00
|
|
|
{
|
2010-05-04 06:38:07 +08:00
|
|
|
const char *set = diff_get_color(use_color, DIFF_METAINFO);
|
|
|
|
const char *reset = diff_get_color(use_color, DIFF_RESET);
|
2013-02-08 04:15:27 +08:00
|
|
|
const char *line_prefix = diff_line_prefix(o);
|
2022-02-02 10:37:34 +08:00
|
|
|
struct strbuf *more_headers = NULL;
|
2010-05-26 15:23:54 +08:00
|
|
|
|
2010-05-26 10:50:12 +08:00
|
|
|
*must_show_header = 1;
|
2009-01-26 16:08:24 +08:00
|
|
|
strbuf_init(msg, PATH_MAX * 2 + 300);
|
|
|
|
switch (p->status) {
|
|
|
|
case DIFF_STATUS_COPIED:
|
2010-06-19 02:16:57 +08:00
|
|
|
strbuf_addf(msg, "%s%ssimilarity index %d%%",
|
|
|
|
line_prefix, set, similarity_index(p));
|
|
|
|
strbuf_addf(msg, "%s\n%s%scopy from ",
|
|
|
|
reset, line_prefix, set);
|
2009-01-26 16:08:24 +08:00
|
|
|
quote_c_style(name, msg, NULL, 0);
|
2010-06-19 02:16:57 +08:00
|
|
|
strbuf_addf(msg, "%s\n%s%scopy to ", reset, line_prefix, set);
|
2009-01-26 16:08:24 +08:00
|
|
|
quote_c_style(other, msg, NULL, 0);
|
2010-05-04 06:38:07 +08:00
|
|
|
strbuf_addf(msg, "%s\n", reset);
|
2009-01-26 16:08:24 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_RENAMED:
|
2010-06-19 02:16:57 +08:00
|
|
|
strbuf_addf(msg, "%s%ssimilarity index %d%%",
|
|
|
|
line_prefix, set, similarity_index(p));
|
|
|
|
strbuf_addf(msg, "%s\n%s%srename from ",
|
|
|
|
reset, line_prefix, set);
|
2009-01-26 16:08:24 +08:00
|
|
|
quote_c_style(name, msg, NULL, 0);
|
2010-06-19 02:16:57 +08:00
|
|
|
strbuf_addf(msg, "%s\n%s%srename to ",
|
|
|
|
reset, line_prefix, set);
|
2009-01-26 16:08:24 +08:00
|
|
|
quote_c_style(other, msg, NULL, 0);
|
2010-05-04 06:38:07 +08:00
|
|
|
strbuf_addf(msg, "%s\n", reset);
|
2009-01-26 16:08:24 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_MODIFIED:
|
|
|
|
if (p->score) {
|
2010-06-19 02:16:57 +08:00
|
|
|
strbuf_addf(msg, "%s%sdissimilarity index %d%%%s\n",
|
|
|
|
line_prefix,
|
2010-05-04 06:38:07 +08:00
|
|
|
set, similarity_index(p), reset);
|
2009-01-26 16:08:24 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* fallthru */
|
|
|
|
default:
|
2010-05-26 10:50:12 +08:00
|
|
|
*must_show_header = 0;
|
2009-01-26 16:08:24 +08:00
|
|
|
}
|
2022-02-02 10:37:34 +08:00
|
|
|
if ((more_headers = additional_headers(o, name))) {
|
|
|
|
add_formatted_headers(msg, more_headers,
|
|
|
|
line_prefix, set, reset);
|
|
|
|
*must_show_header = 1;
|
|
|
|
}
|
2018-08-29 05:22:48 +08:00
|
|
|
if (one && two && !oideq(&one->oid, &two->oid)) {
|
2018-05-02 08:25:52 +08:00
|
|
|
const unsigned hexsz = the_hash_algo->hexsz;
|
diff: index-line: respect --abbrev in object's name
A handful of Git's commands respect `--abbrev' for customizing length
of abbreviation of object names.
For diff-family, Git supports 2 different options for 2 different
purposes, `--full-index' for showing diff-patch object's name in full,
and `--abbrev' to customize the length of object names in diff-raw and
diff-tree header lines, without any options to customise the length of
object names in diff-patch format. When working with diff-patch format,
we only have two options, either full index, or default abbrev length.
Although, that behaviour is documented, it doesn't stop users from
trying to use `--abbrev' with the hope of customising diff-patch's
objects' name's abbreviation.
Let's allow the blob object names shown on the "index" line to be
abbreviated to arbitrary length given via the "--abbrev" option.
To preserve backward compatibility with old script that specify both
`--full-index' and `--abbrev', always show full object id
if `--full-index' is specified.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21 19:51:47 +08:00
|
|
|
int abbrev = o->abbrev ? o->abbrev : DEFAULT_ABBREV;
|
|
|
|
|
|
|
|
if (o->flags.full_index)
|
|
|
|
abbrev = hexsz;
|
2009-01-26 16:08:24 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.binary) {
|
2009-01-26 16:08:24 +08:00
|
|
|
mmfile_t mf;
|
2018-09-21 23:57:19 +08:00
|
|
|
if ((!fill_mmfile(o->repo, &mf, one) &&
|
|
|
|
diff_filespec_is_binary(o->repo, one)) ||
|
|
|
|
(!fill_mmfile(o->repo, &mf, two) &&
|
|
|
|
diff_filespec_is_binary(o->repo, two)))
|
2018-05-02 08:25:52 +08:00
|
|
|
abbrev = hexsz;
|
2009-01-26 16:08:24 +08:00
|
|
|
}
|
diff: handle sha1 abbreviations outside of repository
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20 14:21:25 +08:00
|
|
|
strbuf_addf(msg, "%s%sindex %s..%s", line_prefix, set,
|
|
|
|
diff_abbrev_oid(&one->oid, abbrev),
|
|
|
|
diff_abbrev_oid(&two->oid, abbrev));
|
2009-01-26 16:08:24 +08:00
|
|
|
if (one->mode == two->mode)
|
|
|
|
strbuf_addf(msg, " %06o", one->mode);
|
2010-05-04 06:38:07 +08:00
|
|
|
strbuf_addf(msg, "%s\n", reset);
|
2009-01-26 16:08:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static void run_diff_cmd(const char *pgm,
|
|
|
|
const char *name,
|
|
|
|
const char *other,
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
const char *attr_path,
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
2009-01-26 16:08:24 +08:00
|
|
|
struct strbuf *msg,
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 07:51:44 +08:00
|
|
|
struct diff_options *o,
|
2009-01-26 16:08:24 +08:00
|
|
|
struct diff_filepair *p)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2009-01-26 16:08:24 +08:00
|
|
|
const char *xfrm_msg = NULL;
|
|
|
|
int complete_rewrite = (p->status == DIFF_STATUS_MODIFIED) && p->score;
|
2010-05-26 10:50:12 +08:00
|
|
|
int must_show_header = 0;
|
2009-01-26 16:08:24 +08:00
|
|
|
|
2012-07-18 13:08:59 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (o->flags.allow_external) {
|
2018-09-21 23:57:33 +08:00
|
|
|
struct userdiff_driver *drv;
|
|
|
|
|
|
|
|
drv = userdiff_find_by_path(o->repo->index, attr_path);
|
2008-10-06 05:43:21 +08:00
|
|
|
if (drv && drv->external)
|
|
|
|
pgm = drv->external;
|
2007-04-23 08:52:55 +08:00
|
|
|
}
|
|
|
|
|
2010-05-04 06:38:07 +08:00
|
|
|
if (msg) {
|
|
|
|
/*
|
|
|
|
* don't use colors when the header is intended for an
|
|
|
|
* external diff driver
|
|
|
|
*/
|
|
|
|
fill_metainfo(msg, name, other, one, two, o, p,
|
2010-06-19 02:16:57 +08:00
|
|
|
&must_show_header,
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 13:04:23 +08:00
|
|
|
want_color(o->use_color) && !pgm);
|
2010-05-04 06:38:07 +08:00
|
|
|
xfrm_msg = msg->len ? msg->buf : NULL;
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (pgm) {
|
2019-02-14 13:49:42 +08:00
|
|
|
run_external_diff(pgm, name, other, one, two, xfrm_msg, o);
|
2006-04-22 14:57:45 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (one && two)
|
|
|
|
builtin_diff(name, other ? other : name,
|
2010-05-26 10:50:12 +08:00
|
|
|
one, two, xfrm_msg, must_show_header,
|
|
|
|
o, complete_rewrite);
|
2006-04-22 14:57:45 +08:00
|
|
|
else
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(o->file, "* Unmerged path %s\n", name);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:31 +08:00
|
|
|
static void diff_fill_oid_info(struct diff_filespec *one, struct index_state *istate)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
if (DIFF_FILE_VALID(one)) {
|
2016-06-25 07:09:24 +08:00
|
|
|
if (!one->oid_valid) {
|
2006-04-22 14:57:45 +08:00
|
|
|
struct stat st;
|
2012-06-28 11:14:47 +08:00
|
|
|
if (one->is_stdin) {
|
2016-06-25 07:09:23 +08:00
|
|
|
oidclr(&one->oid);
|
2007-02-26 06:36:10 +08:00
|
|
|
return;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
if (lstat(one->path, &st) < 0)
|
2009-06-27 23:58:47 +08:00
|
|
|
die_errno("stat '%s'", one->path);
|
2018-09-21 23:57:31 +08:00
|
|
|
if (index_path(istate, &one->oid, one->path, &st, 0))
|
2009-01-05 02:38:41 +08:00
|
|
|
die("cannot hash %s", one->path);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2016-06-25 07:09:23 +08:00
|
|
|
oidclr(&one->oid);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
static void strip_prefix(int prefix_length, const char **namep, const char **otherp)
|
|
|
|
{
|
|
|
|
/* Strip the prefix but do not molest /dev/null and absolute paths */
|
2018-10-20 00:58:07 +08:00
|
|
|
if (*namep && !is_absolute_path(*namep)) {
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
*namep += prefix_length;
|
diff: strip extra "/" when stripping prefix
There are two ways a user might want to use "diff --relative":
1. For a file in a directory, like "subdir/file", the user
can use "--relative=subdir/" to strip the directory.
2. To strip part of a filename, like "foo-10", they can
use "--relative=foo-".
We currently handle both of those situations. However, if the user passes
"--relative=subdir" (without the trailing slash), we produce inconsistent
results. For the unified diff format, we collapse the double-slash of
"a//file" correctly into "a/file". But for other formats (raw, stat,
name-status), we end up with "/file".
We can do what the user means here and strip the extra "/" (and only a
slash). We are not hurting any existing users of (2) above with this
behavior change because the existing output for this case was nonsensical.
Patch by Jakub, tests and commit message by Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-09 22:50:53 +08:00
|
|
|
if (**namep == '/')
|
|
|
|
++*namep;
|
|
|
|
}
|
2018-10-20 00:58:07 +08:00
|
|
|
if (*otherp && !is_absolute_path(*otherp)) {
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
*otherp += prefix_length;
|
diff: strip extra "/" when stripping prefix
There are two ways a user might want to use "diff --relative":
1. For a file in a directory, like "subdir/file", the user
can use "--relative=subdir/" to strip the directory.
2. To strip part of a filename, like "foo-10", they can
use "--relative=foo-".
We currently handle both of those situations. However, if the user passes
"--relative=subdir" (without the trailing slash), we produce inconsistent
results. For the unified diff format, we collapse the double-slash of
"a//file" correctly into "a/file". But for other formats (raw, stat,
name-status), we end up with "/file".
We can do what the user means here and strip the extra "/" (and only a
slash). We are not hurting any existing users of (2) above with this
behavior change because the existing output for this case was nonsensical.
Patch by Jakub, tests and commit message by Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-09 22:50:53 +08:00
|
|
|
if (**otherp == '/')
|
|
|
|
++*otherp;
|
|
|
|
}
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
static void run_diff(struct diff_filepair *p, struct diff_options *o)
|
|
|
|
{
|
|
|
|
const char *pgm = external_diff();
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
struct strbuf msg;
|
|
|
|
struct diff_filespec *one = p->one;
|
|
|
|
struct diff_filespec *two = p->two;
|
2006-04-22 14:57:45 +08:00
|
|
|
const char *name;
|
|
|
|
const char *other;
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
const char *attr_path;
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
|
2017-06-30 08:06:46 +08:00
|
|
|
name = one->path;
|
|
|
|
other = (strcmp(name, two->path) ? two->path : NULL);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
attr_path = name;
|
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!o->flags.allow_external)
|
2012-07-18 13:08:59 +08:00
|
|
|
pgm = NULL;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (DIFF_PAIR_UNMERGED(p)) {
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
run_diff_cmd(pgm, name, NULL, attr_path,
|
2009-01-26 16:08:24 +08:00
|
|
|
NULL, NULL, NULL, o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:31 +08:00
|
|
|
diff_fill_oid_info(one, o->repo->index);
|
|
|
|
diff_fill_oid_info(two, o->repo->index);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (!pgm &&
|
|
|
|
DIFF_FILE_VALID(one) && DIFF_FILE_VALID(two) &&
|
|
|
|
(S_IFMT & one->mode) != (S_IFMT & two->mode)) {
|
2009-01-26 16:08:24 +08:00
|
|
|
/*
|
|
|
|
* a filepair that changes between file and symlink
|
2006-04-22 14:57:45 +08:00
|
|
|
* needs to be split into deletion and creation.
|
|
|
|
*/
|
|
|
|
struct diff_filespec *null = alloc_filespec(two->path);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
run_diff_cmd(NULL, name, other, attr_path,
|
2018-09-21 23:57:19 +08:00
|
|
|
one, null, &msg,
|
|
|
|
o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
free(null);
|
2009-01-26 16:08:24 +08:00
|
|
|
strbuf_release(&msg);
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
null = alloc_filespec(one->path);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
run_diff_cmd(NULL, name, other, attr_path,
|
2009-01-26 16:08:24 +08:00
|
|
|
null, two, &msg, o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
free(null);
|
|
|
|
}
|
|
|
|
else
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
run_diff_cmd(pgm, name, other, attr_path,
|
2009-01-26 16:08:24 +08:00
|
|
|
one, two, &msg, o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
strbuf_release(&msg);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void run_diffstat(struct diff_filepair *p, struct diff_options *o,
|
|
|
|
struct diffstat_t *diffstat)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
const char *other;
|
|
|
|
|
|
|
|
if (DIFF_PAIR_UNMERGED(p)) {
|
|
|
|
/* unmerged */
|
2018-09-21 23:57:19 +08:00
|
|
|
builtin_diffstat(p->one->path, NULL, NULL, NULL,
|
|
|
|
diffstat, o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
name = p->one->path;
|
|
|
|
other = (strcmp(name, p->two->path) ? p->two->path : NULL);
|
|
|
|
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
|
|
|
|
2018-09-21 23:57:31 +08:00
|
|
|
diff_fill_oid_info(p->one, o->repo->index);
|
|
|
|
diff_fill_oid_info(p->two, o->repo->index);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
builtin_diffstat(name, other, p->one, p->two,
|
|
|
|
diffstat, o, p);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-05-21 05:43:13 +08:00
|
|
|
static void run_checkdiff(struct diff_filepair *p, struct diff_options *o)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
const char *other;
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
const char *attr_path;
|
2006-05-21 05:43:13 +08:00
|
|
|
|
|
|
|
if (DIFF_PAIR_UNMERGED(p)) {
|
|
|
|
/* unmerged */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
name = p->one->path;
|
|
|
|
other = (strcmp(name, p->two->path) ? p->two->path : NULL);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
attr_path = other ? other : name;
|
|
|
|
|
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
2006-05-21 05:43:13 +08:00
|
|
|
|
2018-09-21 23:57:31 +08:00
|
|
|
diff_fill_oid_info(p->one, o->repo->index);
|
|
|
|
diff_fill_oid_info(p->two, o->repo->index);
|
2006-05-21 05:43:13 +08:00
|
|
|
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
builtin_checkdiff(name, other, attr_path, p->one, p->two, o);
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2019-01-27 08:35:31 +08:00
|
|
|
static void prep_parse_options(struct diff_options *options);
|
|
|
|
|
2018-09-21 23:57:24 +08:00
|
|
|
void repo_diff_setup(struct repository *r, struct diff_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2010-08-05 16:49:55 +08:00
|
|
|
memcpy(options, &default_diff_options, sizeof(*options));
|
2008-03-10 10:43:39 +08:00
|
|
|
|
|
|
|
options->file = stdout;
|
2018-09-21 23:57:24 +08:00
|
|
|
options->repo = r;
|
2008-03-10 10:43:39 +08:00
|
|
|
|
2018-08-18 04:43:52 +08:00
|
|
|
options->output_indicators[OUTPUT_INDICATOR_NEW] = '+';
|
|
|
|
options->output_indicators[OUTPUT_INDICATOR_OLD] = '-';
|
|
|
|
options->output_indicators[OUTPUT_INDICATOR_CONTEXT] = ' ';
|
diff: handle --no-abbrev in no-index case
There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.
setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)
Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.
The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.
Signed-off-by: Jack Bates <jack@nottheoilrig.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-07 00:56:14 +08:00
|
|
|
options->abbrev = DEFAULT_ABBREV;
|
2006-04-22 14:57:45 +08:00
|
|
|
options->line_termination = '\n';
|
|
|
|
options->break_opt = -1;
|
|
|
|
options->rename_limit = -1;
|
2011-04-29 17:36:20 +08:00
|
|
|
options->dirstat_permille = diff_dirstat_permille_default;
|
2012-09-28 03:12:52 +08:00
|
|
|
options->context = diff_context_default;
|
2017-01-12 20:21:11 +08:00
|
|
|
options->interhunkcontext = diff_interhunk_context_default;
|
2016-10-05 06:26:27 +08:00
|
|
|
options->ws_error_highlight = ws_error_highlight_default;
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.rename_empty = 1;
|
2020-05-22 18:46:18 +08:00
|
|
|
options->flags.relative_name = diff_relative;
|
2018-01-05 06:50:42 +08:00
|
|
|
options->objfind = NULL;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
Previously diff_tree(), which is now named ll_diff_tree_sha1(), was
generating diff_filepair(s) for two trees t1 and t2, and that was
usually used for a commit as t1=HEAD~, and t2=HEAD - i.e. to see changes
a commit introduces.
In Git, however, we have fundamentally built flexibility in that a
commit can have many parents - 1 for a plain commit, 2 for a simple merge,
but also more than 2 for merging several heads at once.
For merges there is a so called combine-diff, which shows diff, a merge
introduces by itself, omitting changes done by any parent. That works
through first finding paths, that are different to all parents, and then
showing generalized diff, with separate columns for +/- for each parent.
The code lives in combine-diff.c .
There is an impedance mismatch, however, in that a commit could
generally have any number of parents, and that while diffing trees, we
divide cases for 2-tree diffs and more-than-2-tree diffs. I mean there
is no special casing for multiple parents commits in e.g.
revision-walker .
That impedance mismatch *hurts* *performance* *badly* for generating
combined diffs - in "combine-diff: optimize combine_diff_path
sets intersection" I've already removed some slowness from it, but from
the timings provided there, it could be seen, that combined diffs still
cost more than an order of magnitude more cpu time, compared to diff for
usual commits, and that would only be an optimistic estimate, if we take
into account that for e.g. linux.git there is only one merge for several
dozens of plain commits.
That slowness comes from the fact that currently, while generating
combined diff, a lot of time is spent computing diff(commit,commit^2)
just to only then intersect that huge diff to almost small set of files
from diff(commit,commit^1).
That's because at present, to compute combine-diff, for first finding
paths, that "every parent touches", we use the following combine-diff
property/definition:
D(A,P1...Pn) = D(A,P1) ^ ... ^ D(A,Pn) (w.r.t. paths)
where
D(A,P1...Pn) is combined diff between commit A, and parents Pi
and
D(A,Pi) is usual two-tree diff Pi..A
So if any of that D(A,Pi) is huge, tracting 1 n-parent combine-diff as n
1-parent diffs and intersecting results will be slow.
And usually, for linux.git and other topic-based workflows, that
D(A,P2) is huge, because, if merge-base of A and P2, is several dozens
of merges (from A, via first parent) below, that D(A,P2) will be diffing
sum of merges from several subsystems to 1 subsystem.
The solution is to avoid computing n 1-parent diffs, and to find
changed-to-all-parents paths via scanning A's and all Pi's trees
simultaneously, at each step comparing their entries, and based on that
comparison, populate paths result, and deduce we could *skip*
*recursing* into subdirectories, if at least for 1 parent, sha1 of that
dir tree is the same as in A. That would save us from doing significant
amount of needless work.
Such approach is very similar to what diff_tree() does, only there we
deal with scanning only 2 trees simultaneously, and for n+1 tree, the
logic is a bit more complex:
D(T,P1...Pn) calculation scheme
-------------------------------
D(T,P1...Pn) = D(T,P1) ^ ... ^ D(T,Pn) (regarding resulting paths set)
D(T,Pj) - diff between T..Pj
D(T,P1...Pn) - combined diff from T to parents P1,...,Pn
We start from all trees, which are sorted, and compare their entries in
lock-step:
T P1 Pn
- - -
|t| |p1| |pn|
|-| |--| ... |--| imin = argmin(p1...pn)
| | | | | |
|-| |--| |--|
|.| |. | |. |
. . .
. . .
at any time there could be 3 cases:
1) t < p[imin];
2) t > p[imin];
3) t = p[imin].
Schematic deduction of what every case means, and what to do, follows:
1) t < p[imin] -> ∀j t ∉ Pj -> "+t" ∈ D(T,Pj) -> D += "+t"; t↓
2) t > p[imin]
2.1) ∃j: pj > p[imin] -> "-p[imin]" ∉ D(T,Pj) -> D += ø; ∀ pi=p[imin] pi↓
2.2) ∀i pi = p[imin] -> pi ∉ T -> "-pi" ∈ D(T,Pi) -> D += "-p[imin]"; ∀i pi↓
3) t = p[imin]
3.1) ∃j: pj > p[imin] -> "+t" ∈ D(T,Pj) -> only pi=p[imin] remains to investigate
3.2) pi = p[imin] -> investigate δ(t,pi)
|
|
v
3.1+3.2) looking at δ(t,pi) ∀i: pi=p[imin] - if all != ø ->
⎧δ(t,pi) - if pi=p[imin]
-> D += ⎨
⎩"+t" - if pi>p[imin]
in any case t↓ ∀ pi=p[imin] pi↓
~
For comparison, here is how diff_tree() works:
D(A,B) calculation scheme
-------------------------
A B
- -
|a| |b| a < b -> a ∉ B -> D(A,B) += +a a↓
|-| |-| a > b -> b ∉ A -> D(A,B) += -b b↓
| | | | a = b -> investigate δ(a,b) a↓ b↓
|-| |-|
|.| |.|
. .
. .
~~~~~~~~
This patch generalizes diff tree-walker to work with arbitrary number of
parents as described above - i.e. now there is a resulting tree t, and
some parents trees tp[i] i=[0..nparent). The generalization builds on
the fact that usual diff
D(A,B)
is by definition the same as combined diff
D(A,[B]),
so if we could rework the code for common case and make it be not slower
for nparent=1 case, usual diff(t1,t2) generation will not be slower, and
multiparent diff tree-walker would greatly benefit generating
combine-diff.
What we do is as follows:
1) diff tree-walker ll_diff_tree_sha1() is internally reworked to be
a paths generator (new name diff_tree_paths()), with each generated path
being `struct combine_diff_path` with info for path, new sha1,mode and for
every parent which sha1,mode it was in it.
2) From that info, we can still generate usual diff queue with
struct diff_filepairs, via "exporting" generated
combine_diff_path, if we know we run for nparent=1 case.
(see emit_diff() which is now named emit_diff_first_parent_only())
3) In order for diff_can_quit_early(), which checks
DIFF_OPT_TST(opt, HAS_CHANGES))
to work, that exporting have to be happening not in bulk, but
incrementally, one diff path at a time.
For such consumers, there is a new callback in diff_options
introduced:
->pathchange(opt, struct combine_diff_path *)
which, if set to !NULL, is called for every generated path.
(see new compat ll_diff_tree_sha1() wrapper around new paths
generator for setup)
4) The paths generation itself, is reworked from previous
ll_diff_tree_sha1() code according to "D(A,P1...Pn) calculation
scheme" provided above:
On the start we allocate [nparent] arrays in place what was
earlier just for one parent tree.
then we just generalize loops, and comparison according to the
algorithm.
Some notes(*):
1) alloca(), for small arrays, is used for "runs not slower for
nparent=1 case than before" goal - if we change it to xmalloc()/free()
the timings get ~1% worse. For alloca() we use just-introduced
xalloca/xalloca_free compatibility wrappers, so it should not be a
portability problem.
2) For every parent tree, we need to keep a tag, whether entry from that
parent equals to entry from minimal parent. For performance reasons I'm
keeping that tag in entry's mode field in unused bit - see S_IFXMIN_NEQ.
Not doing so, we'd need to alloca another [nparent] array, which hurts
performance.
3) For emitted paths, memory could be reused, if we know the path was
processed via callback and will not be needed later. We use efficient
hand-made realloc-style path_appendnew(), that saves us from ~1-1.5%
of potential additional slowdown.
4) goto(s) are used in several places, as the code executes a little bit
faster with lowered register pressure.
Also
- we should now check for FIND_COPIES_HARDER not only when two entries
names are the same, and their hashes are equal, but also for a case,
when a path was removed from some of all parents having it.
The reason is, if we don't, that path won't be emitted at all (see
"a > xi" case), and we'll just skip it, and FIND_COPIES_HARDER wants
all paths - with diff or without - to be emitted, to be later analyzed
for being copies sources.
The new check is only necessary for nparent >1, as for nparent=1 case
xmin_eqtotal always =1 =nparent, and a path is always added to diff as
removal.
~~~~~~~~
Timings for
# without -c, i.e. testing only nparent=1 case
`git log --raw --no-abbrev --no-renames`
before and after the patch are as follows:
navy.git linux.git v3.10..v3.11
before 0.611s 1.889s
after 0.619s 1.907s
slowdown 1.3% 0.9%
This timings show we did no harm to usual diff(tree1,tree2) generation.
From the table we can see that we actually did ~1% slowdown, but I think
I've "earned" that 1% in the previous patch ("tree-diff: reuse base
str(buf) memory on sub-tree recursion", HEAD~~) so for nparent=1 case,
net timings stays approximately the same.
The output also stayed the same.
(*) If we revert 1)-4) to more usual techniques, for nparent=1 case,
we'll get ~2-2.5% of additional slowdown, which I've tried to avoid, as
"do no harm for nparent=1 case" rule.
For linux.git, combined diff will run an order of magnitude faster and
appropriate timings will be provided in the next commit, as we'll be
taking advantage of the new diff tree-walker for combined-diff
generation there.
P.S. and combined diff is not some exotic/for-play-only stuff - for
example for a program I write to represent Git archives as readonly
filesystem, there is initial scan with
`git log --reverse --raw --no-abbrev --no-renames -c`
to extract log of what was created/changed when, as a result building a
map
{} sha1 -> in which commit (and date) a content was added
that `-c` means also show combined diff for merges, and without them, if
a merge is non-trivial (merges changes from two parents with both having
separate changes to a file), or an evil one, the map will not be full,
i.e. some valid sha1 would be absent from it.
That case was my initial motivation for combined diffs speedup.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-07 05:46:26 +08:00
|
|
|
/* pathchange left =NULL by default */
|
2006-04-22 14:57:45 +08:00
|
|
|
options->change = diff_change;
|
|
|
|
options->add_remove = diff_addremove;
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = diff_use_color_default;
|
2006-07-07 19:01:23 +08:00
|
|
|
options->detect_rename = diff_detect_rename_default;
|
2013-01-16 15:51:57 +08:00
|
|
|
options->xdl_opts |= diff_algorithm;
|
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 17:44:51 +08:00
|
|
|
if (diff_indent_heuristic)
|
|
|
|
DIFF_XDL_SET(options, INDENT_HEURISTIC);
|
2007-12-19 03:32:14 +08:00
|
|
|
|
2013-12-19 08:08:12 +08:00
|
|
|
options->orderfile = diff_order_file_cfg;
|
|
|
|
|
2020-11-10 16:39:00 +08:00
|
|
|
if (!options->flags.ignore_submodule_set)
|
|
|
|
options->flags.ignore_untracked_in_submodules = 1;
|
|
|
|
|
2010-05-03 10:03:41 +08:00
|
|
|
if (diff_no_prefix) {
|
|
|
|
options->a_prefix = options->b_prefix = "";
|
|
|
|
} else if (!diff_mnemonic_prefix) {
|
2008-08-19 11:08:09 +08:00
|
|
|
options->a_prefix = "a/";
|
|
|
|
options->b_prefix = "b/";
|
|
|
|
}
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
|
|
|
options->color_moved = diff_color_moved_default;
|
2018-07-19 03:31:56 +08:00
|
|
|
options->color_moved_ws_handling = diff_color_moved_ws_default;
|
2019-01-27 08:35:31 +08:00
|
|
|
|
|
|
|
prep_parse_options(options);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2022-01-28 20:02:49 +08:00
|
|
|
static const char diff_status_letters[] = {
|
|
|
|
DIFF_STATUS_ADDED,
|
|
|
|
DIFF_STATUS_COPIED,
|
|
|
|
DIFF_STATUS_DELETED,
|
|
|
|
DIFF_STATUS_MODIFIED,
|
|
|
|
DIFF_STATUS_RENAMED,
|
|
|
|
DIFF_STATUS_TYPE_CHANGED,
|
|
|
|
DIFF_STATUS_UNKNOWN,
|
|
|
|
DIFF_STATUS_UNMERGED,
|
|
|
|
DIFF_STATUS_FILTER_AON,
|
|
|
|
DIFF_STATUS_FILTER_BROKEN,
|
|
|
|
'\0',
|
|
|
|
};
|
|
|
|
|
|
|
|
static unsigned int filter_bit['Z' + 1];
|
|
|
|
|
|
|
|
static void prepare_filter_bits(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!filter_bit[DIFF_STATUS_ADDED]) {
|
|
|
|
for (i = 0; diff_status_letters[i]; i++)
|
|
|
|
filter_bit[(int) diff_status_letters[i]] = (1 << i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned filter_bit_tst(char status, const struct diff_options *opt)
|
|
|
|
{
|
|
|
|
return opt->filter & filter_bit[(int) status];
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned diff_filter_bit(char status)
|
|
|
|
{
|
|
|
|
prepare_filter_bits();
|
|
|
|
return filter_bit[(int) status];
|
|
|
|
}
|
|
|
|
|
2012-08-03 20:16:24 +08:00
|
|
|
void diff_setup_done(struct diff_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2018-01-05 06:50:44 +08:00
|
|
|
unsigned check_mask = DIFF_FORMAT_NAME |
|
|
|
|
DIFF_FORMAT_NAME_STATUS |
|
|
|
|
DIFF_FORMAT_CHECKDIFF |
|
|
|
|
DIFF_FORMAT_NO_OUTPUT;
|
2018-05-02 08:25:52 +08:00
|
|
|
/*
|
|
|
|
* This must be signed because we're comparing against a potentially
|
|
|
|
* negative value.
|
|
|
|
*/
|
|
|
|
const int hexsz = the_hash_algo->hexsz;
|
2006-06-25 01:26:49 +08:00
|
|
|
|
2013-05-10 23:10:11 +08:00
|
|
|
if (options->set_default)
|
|
|
|
options->set_default(options);
|
|
|
|
|
2018-01-05 06:50:44 +08:00
|
|
|
if (HAS_MULTI_BITS(options->output_format & check_mask))
|
2022-01-06 04:02:24 +08:00
|
|
|
die(_("options '%s', '%s', '%s', and '%s' cannot be used together"),
|
|
|
|
"--name-only", "--name-status", "--check", "-s");
|
2006-06-25 01:26:49 +08:00
|
|
|
|
2018-01-05 06:50:43 +08:00
|
|
|
if (HAS_MULTI_BITS(options->pickaxe_opts & DIFF_PICKAXE_KINDS_MASK))
|
2022-01-06 04:02:24 +08:00
|
|
|
die(_("options '%s', '%s', and '%s' cannot be used together"),
|
|
|
|
"-G", "-S", "--find-object");
|
2018-01-05 06:50:43 +08:00
|
|
|
|
2021-04-13 01:15:14 +08:00
|
|
|
if (HAS_MULTI_BITS(options->pickaxe_opts & DIFF_PICKAXE_KINDS_G_REGEX_MASK))
|
2022-01-06 04:02:24 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together, use '%s' with '%s'"),
|
|
|
|
"-G", "--pickaxe-regex", "--pickaxe-regex", "-S");
|
2021-04-13 01:15:14 +08:00
|
|
|
|
2021-04-13 01:15:15 +08:00
|
|
|
if (HAS_MULTI_BITS(options->pickaxe_opts & DIFF_PICKAXE_KINDS_ALL_OBJFIND_MASK))
|
2022-01-06 04:02:24 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together, use '%s' with '%s' and '%s'"),
|
|
|
|
"--pickaxe-all", "--find-object", "--pickaxe-all", "-G", "-S");
|
2021-04-13 01:15:15 +08:00
|
|
|
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
/*
|
|
|
|
* Most of the time we can say "there are changes"
|
|
|
|
* only by checking if there are changed paths, but
|
|
|
|
* --ignore-whitespace* options force us to look
|
2009-08-31 04:27:02 +08:00
|
|
|
* inside contents.
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
*/
|
|
|
|
|
2020-12-17 09:27:13 +08:00
|
|
|
if ((options->xdl_opts & XDF_WHITESPACE_FLAGS) ||
|
|
|
|
options->ignore_regex_nr)
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.diff_from_contents = 1;
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
else
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.diff_from_contents = 0;
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.find_copies_harder)
|
2006-08-10 04:17:19 +08:00
|
|
|
options->detect_rename = DIFF_DETECT_COPY;
|
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!options->flags.relative_name)
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
options->prefix = NULL;
|
|
|
|
if (options->prefix)
|
|
|
|
options->prefix_length = strlen(options->prefix);
|
|
|
|
else
|
|
|
|
options->prefix_length = 0;
|
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
if (options->output_format & (DIFF_FORMAT_NAME |
|
|
|
|
DIFF_FORMAT_NAME_STATUS |
|
|
|
|
DIFF_FORMAT_CHECKDIFF |
|
|
|
|
DIFF_FORMAT_NO_OUTPUT))
|
|
|
|
options->output_format &= ~(DIFF_FORMAT_RAW |
|
2006-10-12 18:01:00 +08:00
|
|
|
DIFF_FORMAT_NUMSTAT |
|
2006-06-25 01:21:53 +08:00
|
|
|
DIFF_FORMAT_DIFFSTAT |
|
2006-12-15 12:15:44 +08:00
|
|
|
DIFF_FORMAT_SHORTSTAT |
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
DIFF_FORMAT_DIRSTAT |
|
2006-06-25 01:21:53 +08:00
|
|
|
DIFF_FORMAT_SUMMARY |
|
|
|
|
DIFF_FORMAT_PATCH);
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* These cases always need recursive; we do not drop caller-supplied
|
|
|
|
* recursive bits for other formats here.
|
|
|
|
*/
|
2006-06-25 01:21:53 +08:00
|
|
|
if (options->output_format & (DIFF_FORMAT_PATCH |
|
2006-10-12 18:01:00 +08:00
|
|
|
DIFF_FORMAT_NUMSTAT |
|
2006-06-25 01:21:53 +08:00
|
|
|
DIFF_FORMAT_DIFFSTAT |
|
2006-12-15 12:15:44 +08:00
|
|
|
DIFF_FORMAT_SHORTSTAT |
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 05:26:31 +08:00
|
|
|
DIFF_FORMAT_DIRSTAT |
|
2006-10-04 05:09:56 +08:00
|
|
|
DIFF_FORMAT_SUMMARY |
|
2006-06-25 01:21:53 +08:00
|
|
|
DIFF_FORMAT_CHECKDIFF))
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.recursive = 1;
|
2006-05-22 15:31:02 +08:00
|
|
|
/*
|
2006-06-28 06:08:19 +08:00
|
|
|
* Also pickaxe would not work very well if you do not say recursive
|
2006-05-22 15:31:02 +08:00
|
|
|
*/
|
2018-01-05 06:50:41 +08:00
|
|
|
if (options->pickaxe_opts & DIFF_PICKAXE_KINDS_MASK)
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.recursive = 1;
|
2010-03-12 05:50:25 +08:00
|
|
|
/*
|
|
|
|
* When patches are generated, submodules diffed against the work tree
|
|
|
|
* must be checked for dirtiness too so it can be shown in the output
|
|
|
|
*/
|
|
|
|
if (options->output_format & DIFF_FORMAT_PATCH)
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.dirty_submodules = 1;
|
2006-05-22 15:31:02 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (options->detect_rename && options->rename_limit < 0)
|
|
|
|
options->rename_limit = diff_rename_limit_default;
|
2018-05-02 08:25:52 +08:00
|
|
|
if (hexsz < options->abbrev)
|
|
|
|
options->abbrev = hexsz; /* full */
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2007-03-15 02:12:13 +08:00
|
|
|
/*
|
|
|
|
* It does not make sense to show the first hit we happened
|
|
|
|
* to have found. It does not make sense not to return with
|
|
|
|
* exit code in such a case either.
|
|
|
|
*/
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.quick) {
|
2007-03-15 02:12:13 +08:00
|
|
|
options->output_format = DIFF_FORMAT_NO_OUTPUT;
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.exit_with_status = 1;
|
2007-03-15 02:12:13 +08:00
|
|
|
}
|
2013-12-06 07:38:46 +08:00
|
|
|
|
2013-12-17 04:02:21 +08:00
|
|
|
options->diff_path_counter = 0;
|
2014-06-17 01:07:09 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.follow_renames && options->pathspec.nr != 1)
|
2014-05-20 14:49:20 +08:00
|
|
|
die(_("--follow requires exactly one pathspec"));
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
|
|
|
if (!options->use_color || external_diff())
|
|
|
|
options->color_moved = 0;
|
2019-01-27 08:35:31 +08:00
|
|
|
|
diff-filter: be more careful when looking for negative bits
The `--diff-filter=<bits>` option allows to filter the diff by certain
criteria, for example `R` to only show renamed files. It also supports
negating a filter via a down-cased letter, i.e. `r` to show _everything
but_ renamed files.
However, the code is a bit overzealous when trying to figure out whether
`git diff` should start with all diff-filters turned on because the user
provided a lower-case letter: if the `--diff-filter` argument starts
with an upper-case letter, we must not start with all bits turned on.
Even worse, it is possible to specify the diff filters in multiple,
separate options, e.g. `--diff-filter=AM [...] --diff-filter=m`.
Let's accumulate the include/exclude filters independently, and only
special-case the "only exclude filters were specified" case after
parsing the options altogether.
Note: The code replaced by this commit took pains to avoid setting any
unused bits of `options->filter`. That was unnecessary, though, as all
accesses happen via the `filter_bit_tst()` function using specific bits,
and setting the unused bits has no effect. Therefore, we can simplify
the code by using `~0` (or in this instance, `~<unwanted-bit>`).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28 20:02:50 +08:00
|
|
|
if (options->filter_not) {
|
|
|
|
if (!options->filter)
|
|
|
|
options->filter = ~filter_bit[DIFF_STATUS_FILTER_AON];
|
|
|
|
options->filter &= ~options->filter_not;
|
|
|
|
}
|
|
|
|
|
2019-01-27 08:35:31 +08:00
|
|
|
FREE_AND_NULL(options->parseopts);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2010-08-05 16:22:52 +08:00
|
|
|
int parse_long_opt(const char *opt, const char **argv,
|
|
|
|
const char **optarg)
|
|
|
|
{
|
|
|
|
const char *arg = argv[0];
|
2014-06-19 03:48:29 +08:00
|
|
|
if (!skip_prefix(arg, "--", &arg))
|
2010-08-05 16:22:52 +08:00
|
|
|
return 0;
|
2014-06-19 03:48:29 +08:00
|
|
|
if (!skip_prefix(arg, opt, &arg))
|
2010-08-05 16:22:52 +08:00
|
|
|
return 0;
|
2013-10-31 19:08:28 +08:00
|
|
|
if (*arg == '=') { /* stuck form: --option=value */
|
2010-08-05 16:22:52 +08:00
|
|
|
*optarg = arg + 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (*arg != '\0')
|
|
|
|
return 0;
|
|
|
|
/* separate form: --option value */
|
|
|
|
if (!argv[1])
|
|
|
|
die("Option '--%s' requires a value", opt);
|
|
|
|
*optarg = argv[1];
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:10 +08:00
|
|
|
static int diff_opt_stat(const struct option *opt, const char *value, int unset)
|
2010-08-05 16:22:53 +08:00
|
|
|
{
|
2019-02-21 19:16:10 +08:00
|
|
|
struct diff_options *options = opt->value;
|
2010-08-05 16:22:53 +08:00
|
|
|
int width = options->stat_width;
|
|
|
|
int name_width = options->stat_name_width;
|
2012-03-01 20:26:45 +08:00
|
|
|
int graph_width = options->stat_graph_width;
|
2011-05-27 20:36:41 +08:00
|
|
|
int count = options->stat_count;
|
2019-02-21 19:16:10 +08:00
|
|
|
char *end;
|
2010-08-05 16:22:53 +08:00
|
|
|
|
2019-02-21 19:16:10 +08:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
2010-08-05 16:22:53 +08:00
|
|
|
|
2019-02-21 19:16:10 +08:00
|
|
|
if (!strcmp(opt->long_name, "stat")) {
|
|
|
|
if (value) {
|
|
|
|
width = strtoul(value, &end, 10);
|
|
|
|
if (*end == ',')
|
|
|
|
name_width = strtoul(end+1, &end, 10);
|
|
|
|
if (*end == ',')
|
|
|
|
count = strtoul(end+1, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return error(_("invalid --stat value: %s"), value);
|
2010-08-05 16:22:54 +08:00
|
|
|
}
|
2019-02-21 19:16:10 +08:00
|
|
|
} else if (!strcmp(opt->long_name, "stat-width")) {
|
|
|
|
width = strtoul(value, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return error(_("%s expects a numerical value"),
|
|
|
|
opt->long_name);
|
|
|
|
} else if (!strcmp(opt->long_name, "stat-name-width")) {
|
|
|
|
name_width = strtoul(value, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return error(_("%s expects a numerical value"),
|
|
|
|
opt->long_name);
|
|
|
|
} else if (!strcmp(opt->long_name, "stat-graph-width")) {
|
|
|
|
graph_width = strtoul(value, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return error(_("%s expects a numerical value"),
|
|
|
|
opt->long_name);
|
|
|
|
} else if (!strcmp(opt->long_name, "stat-count")) {
|
|
|
|
count = strtoul(value, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return error(_("%s expects a numerical value"),
|
|
|
|
opt->long_name);
|
|
|
|
} else
|
|
|
|
BUG("%s should not get here", opt->long_name);
|
2010-08-05 16:22:53 +08:00
|
|
|
|
|
|
|
options->output_format |= DIFF_FORMAT_DIFFSTAT;
|
|
|
|
options->stat_name_width = name_width;
|
2012-03-01 20:26:45 +08:00
|
|
|
options->stat_graph_width = graph_width;
|
2010-08-05 16:22:53 +08:00
|
|
|
options->stat_width = width;
|
2011-05-27 20:36:41 +08:00
|
|
|
options->stat_count = count;
|
2019-02-21 19:16:10 +08:00
|
|
|
return 0;
|
2010-08-05 16:22:53 +08:00
|
|
|
}
|
|
|
|
|
2011-04-29 17:36:18 +08:00
|
|
|
static int parse_dirstat_opt(struct diff_options *options, const char *params)
|
|
|
|
{
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
struct strbuf errmsg = STRBUF_INIT;
|
|
|
|
if (parse_dirstat_params(options, params, &errmsg))
|
2011-04-29 17:36:23 +08:00
|
|
|
die(_("Failed to parse --dirstat/-X option parameter:\n%s"),
|
Improve error handling when parsing dirstat parameters
When encountering errors or unknown tokens while parsing parameters to the
--dirstat option, it makes sense to die() with an error message informing
the user of which parameter did not make sense. However, when parsing the
diff.dirstat config variable, we cannot simply die(), but should instead
(after warning the user) ignore the erroneous or unrecognized parameter.
After all, future Git versions might add more dirstat parameters, and
using two different Git versions on the same repo should not cripple the
older Git version just because of a parameter that is only understood by
a more recent Git version.
This patch fixes the issue by refactoring the dirstat parameter parsing
so that parse_dirstat_params() keeps on parsing parameters, even if an
earlier parameter was not recognized. When parsing has finished, it returns
zero if all parameters were successfully parsed, and non-zero if one or
more parameters were not recognized (with appropriate error messages
appended to the 'errmsg' argument).
The parse_dirstat_params() callers then decide (based on the return value
from parse_dirstat_params()) whether to warn and ignore (in case of
diff.dirstat), or to warn and die (in case of --dirstat).
The patch also adds a couple of tests verifying the correct behavior of
--dirstat and diff.dirstat in the face of unknown (possibly future) dirstat
parameters.
Suggested-by: Junio C Hamano <gitster@pobox.com>
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 17:36:22 +08:00
|
|
|
errmsg.buf);
|
|
|
|
strbuf_release(&errmsg);
|
2011-04-29 17:36:18 +08:00
|
|
|
/*
|
|
|
|
* The caller knows a dirstat-related option is given from the command
|
|
|
|
* line; allow it to say "return this_function();"
|
|
|
|
*/
|
|
|
|
options->output_format |= DIFF_FORMAT_DIRSTAT;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:03 +08:00
|
|
|
static int diff_opt_diff_filter(const struct option *option,
|
|
|
|
const char *optarg, int unset)
|
2013-07-18 06:05:46 +08:00
|
|
|
{
|
2019-03-24 16:20:03 +08:00
|
|
|
struct diff_options *opt = option->value;
|
2013-07-18 06:05:46 +08:00
|
|
|
int i, optch;
|
|
|
|
|
2019-03-24 16:20:03 +08:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
2013-07-18 06:05:46 +08:00
|
|
|
prepare_filter_bits();
|
2013-07-18 07:19:19 +08:00
|
|
|
|
2013-07-18 06:05:46 +08:00
|
|
|
for (i = 0; (optch = optarg[i]) != '\0'; i++) {
|
|
|
|
unsigned int bit;
|
2013-07-18 07:19:19 +08:00
|
|
|
int negate;
|
|
|
|
|
|
|
|
if ('a' <= optch && optch <= 'z') {
|
|
|
|
negate = 1;
|
|
|
|
optch = toupper(optch);
|
|
|
|
} else {
|
|
|
|
negate = 0;
|
|
|
|
}
|
2013-07-18 06:05:46 +08:00
|
|
|
|
|
|
|
bit = (0 <= optch && optch <= 'Z') ? filter_bit[optch] : 0;
|
|
|
|
if (!bit)
|
2019-03-24 16:20:03 +08:00
|
|
|
return error(_("unknown change class '%c' in --diff-filter=%s"),
|
|
|
|
optarg[i], optarg);
|
2013-07-18 07:19:19 +08:00
|
|
|
if (negate)
|
diff-filter: be more careful when looking for negative bits
The `--diff-filter=<bits>` option allows to filter the diff by certain
criteria, for example `R` to only show renamed files. It also supports
negating a filter via a down-cased letter, i.e. `r` to show _everything
but_ renamed files.
However, the code is a bit overzealous when trying to figure out whether
`git diff` should start with all diff-filters turned on because the user
provided a lower-case letter: if the `--diff-filter` argument starts
with an upper-case letter, we must not start with all bits turned on.
Even worse, it is possible to specify the diff filters in multiple,
separate options, e.g. `--diff-filter=AM [...] --diff-filter=m`.
Let's accumulate the include/exclude filters independently, and only
special-case the "only exclude filters were specified" case after
parsing the options altogether.
Note: The code replaced by this commit took pains to avoid setting any
unused bits of `options->filter`. That was unnecessary, though, as all
accesses happen via the `filter_bit_tst()` function using specific bits,
and setting the unused bits has no effect. Therefore, we can simplify
the code by using `~0` (or in this instance, `~<unwanted-bit>`).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28 20:02:50 +08:00
|
|
|
opt->filter_not |= bit;
|
2013-07-18 07:19:19 +08:00
|
|
|
else
|
|
|
|
opt->filter |= bit;
|
2013-07-18 06:05:46 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-12-09 18:25:21 +08:00
|
|
|
static void enable_patch_output(int *fmt)
|
|
|
|
{
|
2013-07-16 16:05:37 +08:00
|
|
|
*fmt &= ~DIFF_FORMAT_NO_OUTPUT;
|
|
|
|
*fmt |= DIFF_FORMAT_PATCH;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:19:55 +08:00
|
|
|
static int diff_opt_ws_error_highlight(const struct option *option,
|
|
|
|
const char *arg, int unset)
|
2015-05-27 01:11:28 +08:00
|
|
|
{
|
2019-03-24 16:19:55 +08:00
|
|
|
struct diff_options *opt = option->value;
|
2016-10-05 06:03:33 +08:00
|
|
|
int val = parse_ws_error_highlight(arg);
|
2015-05-27 01:11:28 +08:00
|
|
|
|
2019-03-24 16:19:55 +08:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (val < 0)
|
|
|
|
return error(_("unknown value after ws-error-highlight=%.*s"),
|
|
|
|
-1 - val, arg);
|
2015-05-27 01:11:28 +08:00
|
|
|
opt->ws_error_highlight = val;
|
2019-03-24 16:19:55 +08:00
|
|
|
return 0;
|
2015-05-27 01:11:28 +08:00
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:02 +08:00
|
|
|
static int diff_opt_find_object(const struct option *option,
|
|
|
|
const char *arg, int unset)
|
2018-01-05 06:50:42 +08:00
|
|
|
{
|
2019-03-24 16:20:02 +08:00
|
|
|
struct diff_options *opt = option->value;
|
2018-01-05 06:50:42 +08:00
|
|
|
struct object_id oid;
|
|
|
|
|
2019-03-24 16:20:02 +08:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
2018-01-05 06:50:42 +08:00
|
|
|
if (get_oid(arg, &oid))
|
2019-03-24 16:20:02 +08:00
|
|
|
return error(_("unable to resolve '%s'"), arg);
|
2018-01-05 06:50:42 +08:00
|
|
|
|
|
|
|
if (!opt->objfind)
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(opt->objfind, 1);
|
2018-01-05 06:50:42 +08:00
|
|
|
|
|
|
|
opt->pickaxe_opts |= DIFF_PICKAXE_KIND_OBJFIND;
|
|
|
|
opt->flags.recursive = 1;
|
|
|
|
opt->flags.tree_in_recursive = 1;
|
|
|
|
oidset_insert(opt->objfind, &oid);
|
2019-03-24 16:20:02 +08:00
|
|
|
return 0;
|
2018-01-05 06:50:42 +08:00
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:11 +08:00
|
|
|
static int diff_opt_anchored(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
|
|
|
|
ALLOC_GROW(options->anchors, options->anchors_nr + 1,
|
|
|
|
options->anchors_alloc);
|
|
|
|
options->anchors[options->anchors_nr++] = xstrdup(arg);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:12 +08:00
|
|
|
static int diff_opt_binary(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
enable_patch_output(&options->output_format);
|
|
|
|
options->flags.binary = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:13 +08:00
|
|
|
static int diff_opt_break_rewrites(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
int *break_opt = opt->value;
|
|
|
|
int opt1, opt2;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!arg)
|
|
|
|
arg = "";
|
|
|
|
opt1 = parse_rename_score(&arg);
|
|
|
|
if (*arg == 0)
|
|
|
|
opt2 = 0;
|
|
|
|
else if (*arg != '/')
|
|
|
|
return error(_("%s expects <n>/<m> form"), opt->long_name);
|
|
|
|
else {
|
|
|
|
arg++;
|
|
|
|
opt2 = parse_rename_score(&arg);
|
|
|
|
}
|
|
|
|
if (*arg != 0)
|
|
|
|
return error(_("%s expects <n>/<m> form"), opt->long_name);
|
|
|
|
*break_opt = opt1 | (opt2 << 16);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:12 +08:00
|
|
|
static int diff_opt_char(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
char *value = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (arg[1])
|
|
|
|
return error(_("%s expects a character, got '%s'"),
|
|
|
|
opt->long_name, arg);
|
|
|
|
*value = arg[0];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:09 +08:00
|
|
|
static int diff_opt_color_moved(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
if (unset) {
|
|
|
|
options->color_moved = COLOR_MOVED_NO;
|
|
|
|
} else if (!arg) {
|
|
|
|
if (diff_color_moved_default)
|
|
|
|
options->color_moved = diff_color_moved_default;
|
|
|
|
if (options->color_moved == COLOR_MOVED_NO)
|
|
|
|
options->color_moved = COLOR_MOVED_DEFAULT;
|
|
|
|
} else {
|
|
|
|
int cm = parse_color_moved(arg);
|
|
|
|
if (cm < 0)
|
|
|
|
return error(_("bad --color-moved argument: %s"), arg);
|
|
|
|
options->color_moved = cm;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:10 +08:00
|
|
|
static int diff_opt_color_moved_ws(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
unsigned cm;
|
|
|
|
|
2019-03-24 16:20:11 +08:00
|
|
|
if (unset) {
|
|
|
|
options->color_moved_ws_handling = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:10 +08:00
|
|
|
cm = parse_color_moved_ws(arg);
|
|
|
|
if (cm & COLOR_MOVED_WS_ERROR)
|
|
|
|
return error(_("invalid mode '%s' in --color-moved-ws"), arg);
|
|
|
|
options->color_moved_ws_handling = cm;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:20 +08:00
|
|
|
static int diff_opt_color_words(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
options->use_color = 1;
|
|
|
|
options->word_diff = DIFF_WORDS_COLOR;
|
|
|
|
options->word_regex = arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:11 +08:00
|
|
|
static int diff_opt_compact_summary(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
if (unset) {
|
|
|
|
options->flags.stat_with_summary = 0;
|
|
|
|
} else {
|
|
|
|
options->flags.stat_with_summary = 1;
|
|
|
|
options->output_format |= DIFF_FORMAT_DIFFSTAT;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:10 +08:00
|
|
|
static int diff_opt_diff_algorithm(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
long value = parse_algorithm_value(arg);
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (value < 0)
|
|
|
|
return error(_("option diff-algorithm accepts \"myers\", "
|
|
|
|
"\"minimal\", \"patience\" and \"histogram\""));
|
|
|
|
|
|
|
|
/* clear out previous settings */
|
|
|
|
DIFF_XDL_CLR(options, NEED_MINIMAL);
|
|
|
|
options->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK;
|
|
|
|
options->xdl_opts |= value;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:03 +08:00
|
|
|
static int diff_opt_dirstat(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!strcmp(opt->long_name, "cumulative")) {
|
|
|
|
if (arg)
|
|
|
|
BUG("how come --cumulative take a value?");
|
|
|
|
arg = "cumulative";
|
|
|
|
} else if (!strcmp(opt->long_name, "dirstat-by-file"))
|
|
|
|
parse_dirstat_opt(options, "files");
|
|
|
|
parse_dirstat_opt(options, arg ? arg : "");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:16 +08:00
|
|
|
static int diff_opt_find_copies(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!arg)
|
|
|
|
arg = "";
|
|
|
|
options->rename_score = parse_rename_score(&arg);
|
|
|
|
if (*arg != 0)
|
|
|
|
return error(_("invalid argument to %s"), opt->long_name);
|
|
|
|
|
|
|
|
if (options->detect_rename == DIFF_DETECT_COPY)
|
|
|
|
options->flags.find_copies_harder = 1;
|
|
|
|
else
|
|
|
|
options->detect_rename = DIFF_DETECT_COPY;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:14 +08:00
|
|
|
static int diff_opt_find_renames(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!arg)
|
|
|
|
arg = "";
|
|
|
|
options->rename_score = parse_rename_score(&arg);
|
|
|
|
if (*arg != 0)
|
|
|
|
return error(_("invalid argument to %s"), opt->long_name);
|
|
|
|
|
|
|
|
options->detect_rename = DIFF_DETECT_RENAME;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:16 +08:00
|
|
|
static int diff_opt_follow(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
if (unset) {
|
|
|
|
options->flags.follow_renames = 0;
|
|
|
|
options->flags.default_follow_renames = 0;
|
|
|
|
} else {
|
|
|
|
options->flags.follow_renames = 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:25 +08:00
|
|
|
static int diff_opt_ignore_submodules(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!arg)
|
|
|
|
arg = "all";
|
|
|
|
options->flags.override_submodule_config = 1;
|
|
|
|
handle_ignore_submodules_arg(options, arg);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:06 +08:00
|
|
|
static int diff_opt_line_prefix(const struct option *opt,
|
|
|
|
const char *optarg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
options->line_prefix = optarg;
|
|
|
|
options->line_prefix_length = strlen(options->line_prefix);
|
|
|
|
graph_setup_line_prefix(options);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:20:07 +08:00
|
|
|
static int diff_opt_no_prefix(const struct option *opt,
|
|
|
|
const char *optarg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
BUG_ON_OPT_ARG(optarg);
|
|
|
|
options->a_prefix = "";
|
|
|
|
options->b_prefix = "";
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:12 +08:00
|
|
|
static enum parse_opt_result diff_opt_output(struct parse_opt_ctx_t *ctx,
|
|
|
|
const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
char *path;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
path = prefix_filename(ctx->prefix, arg);
|
|
|
|
options->file = xfopen(path, "w");
|
|
|
|
options->close_file = 1;
|
|
|
|
if (options->use_color != GIT_COLOR_ALWAYS)
|
|
|
|
options->use_color = GIT_COLOR_NEVER;
|
|
|
|
free(path);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:08 +08:00
|
|
|
static int diff_opt_patience(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
|
|
|
|
/*
|
|
|
|
* Both --patience and --anchored use PATIENCE_DIFF
|
|
|
|
* internally, so remove any anchors previously
|
|
|
|
* specified.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < options->anchors_nr; i++)
|
|
|
|
free(options->anchors[i]);
|
|
|
|
options->anchors_nr = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-10-20 14:48:09 +08:00
|
|
|
static int diff_opt_ignore_regex(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
regex_t *regex;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
regex = xmalloc(sizeof(*regex));
|
|
|
|
if (regcomp(regex, arg, REG_EXTENDED | REG_NEWLINE))
|
|
|
|
return error(_("invalid regex given to -I: '%s'"), arg);
|
|
|
|
ALLOC_GROW(options->ignore_regex, options->ignore_regex_nr + 1,
|
|
|
|
options->ignore_regex_alloc);
|
|
|
|
options->ignore_regex[options->ignore_regex_nr++] = regex;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-24 16:19:59 +08:00
|
|
|
static int diff_opt_pickaxe_regex(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
options->pickaxe = arg;
|
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_KIND_G;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int diff_opt_pickaxe_string(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
options->pickaxe = arg;
|
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_KIND_S;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-21 19:16:19 +08:00
|
|
|
static int diff_opt_relative(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
2020-05-22 18:46:18 +08:00
|
|
|
options->flags.relative_name = !unset;
|
2019-02-21 19:16:19 +08:00
|
|
|
if (arg)
|
|
|
|
options->prefix = arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:26 +08:00
|
|
|
static int diff_opt_submodule(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!arg)
|
|
|
|
arg = "log";
|
|
|
|
if (parse_submodule_params(options, arg))
|
|
|
|
return error(_("failed to parse --submodule option parameter: '%s'"),
|
|
|
|
arg);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:24 +08:00
|
|
|
static int diff_opt_textconv(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_ARG(arg);
|
|
|
|
if (unset) {
|
|
|
|
options->flags.allow_textconv = 0;
|
|
|
|
} else {
|
|
|
|
options->flags.allow_textconv = 1;
|
|
|
|
options->flags.textconv_set_via_cmdline = 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-27 08:35:33 +08:00
|
|
|
static int diff_opt_unified(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
char *s;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2019-05-29 17:11:15 +08:00
|
|
|
if (arg) {
|
|
|
|
options->context = strtol(arg, &s, 10);
|
|
|
|
if (*s)
|
|
|
|
return error(_("%s expects a numerical value"), "--unified");
|
|
|
|
}
|
2019-01-27 08:35:33 +08:00
|
|
|
enable_patch_output(&options->output_format);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:18 +08:00
|
|
|
static int diff_opt_word_diff(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (arg) {
|
|
|
|
if (!strcmp(arg, "plain"))
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
|
|
|
else if (!strcmp(arg, "color")) {
|
|
|
|
options->use_color = 1;
|
|
|
|
options->word_diff = DIFF_WORDS_COLOR;
|
|
|
|
}
|
|
|
|
else if (!strcmp(arg, "porcelain"))
|
|
|
|
options->word_diff = DIFF_WORDS_PORCELAIN;
|
|
|
|
else if (!strcmp(arg, "none"))
|
|
|
|
options->word_diff = DIFF_WORDS_NONE;
|
|
|
|
else
|
|
|
|
return error(_("bad --word-diff argument: %s"), arg);
|
|
|
|
} else {
|
|
|
|
if (options->word_diff == DIFF_WORDS_NONE)
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-05 20:30:19 +08:00
|
|
|
static int diff_opt_word_diff_regex(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (options->word_diff == DIFF_WORDS_NONE)
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
|
|
|
options->word_regex = arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
diff: --{rotate,skip}-to=<path>
In the implementation of "git difftool", there is a case where the
user wants to start viewing the diffs at a specific path and
continue on to the rest, optionally wrapping around to the
beginning. Since it is somewhat cumbersome to implement such a
feature as a post-processing step of "git diff" output, let's
support it internally with two new options.
- "git diff --rotate-to=C", when the resulting patch would show
paths A B C D E without the option, would "rotate" the paths to
shows patch to C D E A B instead. It is an error when there is
no patch for C is shown.
- "git diff --skip-to=C" would instead "skip" the paths before C,
and shows patch to C D E. Again, it is an error when there is no
patch for C is shown.
- "git log [-p]" also accepts these two options, but it is not an
error if there is no change to the specified path. Instead, the
set of output paths are rotated or skipped to the specified path
or the first path that sorts after the specified path.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-12 03:57:50 +08:00
|
|
|
static int diff_opt_rotate_to(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct diff_options *options = opt->value;
|
|
|
|
|
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
if (!strcmp(opt->long_name, "skip-to"))
|
|
|
|
options->skip_instead_of_rotate = 1;
|
|
|
|
else
|
|
|
|
options->skip_instead_of_rotate = 0;
|
|
|
|
options->rotate_to = arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-27 08:35:31 +08:00
|
|
|
static void prep_parse_options(struct diff_options *options)
|
|
|
|
{
|
|
|
|
struct option parseopts[] = {
|
2019-01-27 08:35:32 +08:00
|
|
|
OPT_GROUP(N_("Diff output format options")),
|
|
|
|
OPT_BITOP('p', "patch", &options->output_format,
|
|
|
|
N_("generate patch"),
|
|
|
|
DIFF_FORMAT_PATCH, DIFF_FORMAT_NO_OUTPUT),
|
2019-02-21 19:16:09 +08:00
|
|
|
OPT_BIT_F('s', "no-patch", &options->output_format,
|
|
|
|
N_("suppress diff output"),
|
|
|
|
DIFF_FORMAT_NO_OUTPUT, PARSE_OPT_NONEG),
|
2019-01-27 08:35:32 +08:00
|
|
|
OPT_BITOP('u', NULL, &options->output_format,
|
|
|
|
N_("generate patch"),
|
|
|
|
DIFF_FORMAT_PATCH, DIFF_FORMAT_NO_OUTPUT),
|
2019-01-27 08:35:33 +08:00
|
|
|
OPT_CALLBACK_F('U', "unified", options, N_("<n>"),
|
|
|
|
N_("generate diffs with <n> lines context"),
|
2019-05-29 17:11:15 +08:00
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG, diff_opt_unified),
|
2019-01-27 08:35:34 +08:00
|
|
|
OPT_BOOL('W', "function-context", &options->flags.funccontext,
|
|
|
|
N_("generate diffs with <n> lines context")),
|
2019-01-27 08:35:35 +08:00
|
|
|
OPT_BIT_F(0, "raw", &options->output_format,
|
|
|
|
N_("generate the diff in raw format"),
|
|
|
|
DIFF_FORMAT_RAW, PARSE_OPT_NONEG),
|
2019-02-16 19:36:35 +08:00
|
|
|
OPT_BITOP(0, "patch-with-raw", &options->output_format,
|
|
|
|
N_("synonym for '-p --raw'"),
|
|
|
|
DIFF_FORMAT_PATCH | DIFF_FORMAT_RAW,
|
|
|
|
DIFF_FORMAT_NO_OUTPUT),
|
2019-02-21 19:16:06 +08:00
|
|
|
OPT_BITOP(0, "patch-with-stat", &options->output_format,
|
|
|
|
N_("synonym for '-p --stat'"),
|
|
|
|
DIFF_FORMAT_PATCH | DIFF_FORMAT_DIFFSTAT,
|
|
|
|
DIFF_FORMAT_NO_OUTPUT),
|
2019-02-16 19:36:36 +08:00
|
|
|
OPT_BIT_F(0, "numstat", &options->output_format,
|
|
|
|
N_("machine friendly --stat"),
|
|
|
|
DIFF_FORMAT_NUMSTAT, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F(0, "shortstat", &options->output_format,
|
|
|
|
N_("output only the last line of --stat"),
|
|
|
|
DIFF_FORMAT_SHORTSTAT, PARSE_OPT_NONEG),
|
2019-02-21 19:16:03 +08:00
|
|
|
OPT_CALLBACK_F('X', "dirstat", options, N_("<param1,param2>..."),
|
|
|
|
N_("output the distribution of relative amount of changes for each sub-directory"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_dirstat),
|
|
|
|
OPT_CALLBACK_F(0, "cumulative", options, NULL,
|
|
|
|
N_("synonym for --dirstat=cumulative"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_NOARG,
|
|
|
|
diff_opt_dirstat),
|
|
|
|
OPT_CALLBACK_F(0, "dirstat-by-file", options, N_("<param1,param2>..."),
|
|
|
|
N_("synonym for --dirstat=files,param1,param2..."),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_dirstat),
|
2019-02-21 19:16:04 +08:00
|
|
|
OPT_BIT_F(0, "check", &options->output_format,
|
|
|
|
N_("warn if changes introduce conflict markers or whitespace errors"),
|
|
|
|
DIFF_FORMAT_CHECKDIFF, PARSE_OPT_NONEG),
|
2019-02-21 19:16:05 +08:00
|
|
|
OPT_BIT_F(0, "summary", &options->output_format,
|
|
|
|
N_("condensed summary such as creations, renames and mode changes"),
|
|
|
|
DIFF_FORMAT_SUMMARY, PARSE_OPT_NONEG),
|
2019-02-21 19:16:07 +08:00
|
|
|
OPT_BIT_F(0, "name-only", &options->output_format,
|
|
|
|
N_("show only names of changed files"),
|
|
|
|
DIFF_FORMAT_NAME, PARSE_OPT_NONEG),
|
2019-02-21 19:16:08 +08:00
|
|
|
OPT_BIT_F(0, "name-status", &options->output_format,
|
|
|
|
N_("show only names and status of changed files"),
|
|
|
|
DIFF_FORMAT_NAME_STATUS, PARSE_OPT_NONEG),
|
2019-02-21 19:16:10 +08:00
|
|
|
OPT_CALLBACK_F(0, "stat", options, N_("<width>[,<name-width>[,<count>]]"),
|
|
|
|
N_("generate diffstat"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG, diff_opt_stat),
|
|
|
|
OPT_CALLBACK_F(0, "stat-width", options, N_("<width>"),
|
|
|
|
N_("generate diffstat with a given width"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_stat),
|
|
|
|
OPT_CALLBACK_F(0, "stat-name-width", options, N_("<width>"),
|
|
|
|
N_("generate diffstat with a given name width"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_stat),
|
|
|
|
OPT_CALLBACK_F(0, "stat-graph-width", options, N_("<width>"),
|
|
|
|
N_("generate diffstat with a given graph width"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_stat),
|
|
|
|
OPT_CALLBACK_F(0, "stat-count", options, N_("<count>"),
|
|
|
|
N_("generate diffstat with limited lines"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_stat),
|
2019-02-21 19:16:11 +08:00
|
|
|
OPT_CALLBACK_F(0, "compact-summary", options, NULL,
|
|
|
|
N_("generate compact summary in diffstat"),
|
|
|
|
PARSE_OPT_NOARG, diff_opt_compact_summary),
|
2019-03-05 20:30:12 +08:00
|
|
|
OPT_CALLBACK_F(0, "binary", options, NULL,
|
|
|
|
N_("output a binary diff that can be applied"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_NOARG, diff_opt_binary),
|
2019-03-05 20:30:13 +08:00
|
|
|
OPT_BOOL(0, "full-index", &options->flags.full_index,
|
|
|
|
N_("show full pre- and post-image object names on the \"index\" lines")),
|
2019-03-05 20:30:17 +08:00
|
|
|
OPT_COLOR_FLAG(0, "color", &options->use_color,
|
|
|
|
N_("show colored diff")),
|
2019-03-24 16:19:55 +08:00
|
|
|
OPT_CALLBACK_F(0, "ws-error-highlight", options, N_("<kind>"),
|
|
|
|
N_("highlight whitespace errors in the 'context', 'old' or 'new' lines in the diff"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_ws_error_highlight),
|
2019-03-24 16:19:57 +08:00
|
|
|
OPT_SET_INT('z', NULL, &options->line_termination,
|
|
|
|
N_("do not munge pathnames and use NULs as output field terminators in --raw or --numstat"),
|
|
|
|
0),
|
2019-03-24 16:20:04 +08:00
|
|
|
OPT__ABBREV(&options->abbrev),
|
2019-03-24 16:20:05 +08:00
|
|
|
OPT_STRING_F(0, "src-prefix", &options->a_prefix, N_("<prefix>"),
|
|
|
|
N_("show the given source prefix instead of \"a/\""),
|
|
|
|
PARSE_OPT_NONEG),
|
|
|
|
OPT_STRING_F(0, "dst-prefix", &options->b_prefix, N_("<prefix>"),
|
2019-06-02 23:11:22 +08:00
|
|
|
N_("show the given destination prefix instead of \"b/\""),
|
2019-03-24 16:20:05 +08:00
|
|
|
PARSE_OPT_NONEG),
|
2019-03-24 16:20:06 +08:00
|
|
|
OPT_CALLBACK_F(0, "line-prefix", options, N_("<prefix>"),
|
|
|
|
N_("prepend an additional prefix to every line of output"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_line_prefix),
|
2019-03-24 16:20:07 +08:00
|
|
|
OPT_CALLBACK_F(0, "no-prefix", options, NULL,
|
|
|
|
N_("do not show any source or destination prefix"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_NOARG, diff_opt_no_prefix),
|
2019-03-24 16:20:08 +08:00
|
|
|
OPT_INTEGER_F(0, "inter-hunk-context", &options->interhunkcontext,
|
|
|
|
N_("show context between diff hunks up to the specified number of lines"),
|
|
|
|
PARSE_OPT_NONEG),
|
2019-02-21 19:16:12 +08:00
|
|
|
OPT_CALLBACK_F(0, "output-indicator-new",
|
|
|
|
&options->output_indicators[OUTPUT_INDICATOR_NEW],
|
|
|
|
N_("<char>"),
|
|
|
|
N_("specify the character to indicate a new line instead of '+'"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_char),
|
|
|
|
OPT_CALLBACK_F(0, "output-indicator-old",
|
|
|
|
&options->output_indicators[OUTPUT_INDICATOR_OLD],
|
|
|
|
N_("<char>"),
|
|
|
|
N_("specify the character to indicate an old line instead of '-'"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_char),
|
|
|
|
OPT_CALLBACK_F(0, "output-indicator-context",
|
|
|
|
&options->output_indicators[OUTPUT_INDICATOR_CONTEXT],
|
|
|
|
N_("<char>"),
|
|
|
|
N_("specify the character to indicate a context instead of ' '"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_char),
|
|
|
|
|
2019-02-21 19:16:13 +08:00
|
|
|
OPT_GROUP(N_("Diff rename options")),
|
|
|
|
OPT_CALLBACK_F('B', "break-rewrites", &options->break_opt, N_("<n>[/<m>]"),
|
|
|
|
N_("break complete rewrite changes into pairs of delete and create"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_break_rewrites),
|
2019-02-21 19:16:14 +08:00
|
|
|
OPT_CALLBACK_F('M', "find-renames", options, N_("<n>"),
|
|
|
|
N_("detect renames"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_find_renames),
|
2019-02-21 19:16:15 +08:00
|
|
|
OPT_SET_INT_F('D', "irreversible-delete", &options->irreversible_delete,
|
|
|
|
N_("omit the preimage for deletes"),
|
|
|
|
1, PARSE_OPT_NONEG),
|
2019-02-21 19:16:16 +08:00
|
|
|
OPT_CALLBACK_F('C', "find-copies", options, N_("<n>"),
|
|
|
|
N_("detect copies"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_find_copies),
|
2019-02-21 19:16:17 +08:00
|
|
|
OPT_BOOL(0, "find-copies-harder", &options->flags.find_copies_harder,
|
|
|
|
N_("use unmodified files as source to find copies")),
|
2019-02-21 19:16:18 +08:00
|
|
|
OPT_SET_INT_F(0, "no-renames", &options->detect_rename,
|
|
|
|
N_("disable rename detection"),
|
|
|
|
0, PARSE_OPT_NONEG),
|
|
|
|
OPT_BOOL(0, "rename-empty", &options->flags.rename_empty,
|
|
|
|
N_("use empty blobs as rename source")),
|
2019-03-05 20:30:16 +08:00
|
|
|
OPT_CALLBACK_F(0, "follow", options, NULL,
|
|
|
|
N_("continue listing the history of a file beyond renames"),
|
|
|
|
PARSE_OPT_NOARG, diff_opt_follow),
|
2019-03-24 16:19:58 +08:00
|
|
|
OPT_INTEGER('l', NULL, &options->rename_limit,
|
|
|
|
N_("prevent rename/copy detection if the number of rename/copy targets exceeds given limit")),
|
2019-02-21 19:16:13 +08:00
|
|
|
|
2019-02-21 19:16:20 +08:00
|
|
|
OPT_GROUP(N_("Diff algorithm options")),
|
|
|
|
OPT_BIT(0, "minimal", &options->xdl_opts,
|
|
|
|
N_("produce the smallest possible diff"),
|
|
|
|
XDF_NEED_MINIMAL),
|
2019-02-21 19:16:21 +08:00
|
|
|
OPT_BIT_F('w', "ignore-all-space", &options->xdl_opts,
|
|
|
|
N_("ignore whitespace when comparing lines"),
|
|
|
|
XDF_IGNORE_WHITESPACE, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F('b', "ignore-space-change", &options->xdl_opts,
|
|
|
|
N_("ignore changes in amount of whitespace"),
|
|
|
|
XDF_IGNORE_WHITESPACE_CHANGE, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F(0, "ignore-space-at-eol", &options->xdl_opts,
|
|
|
|
N_("ignore changes in whitespace at EOL"),
|
|
|
|
XDF_IGNORE_WHITESPACE_AT_EOL, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F(0, "ignore-cr-at-eol", &options->xdl_opts,
|
|
|
|
N_("ignore carrier-return at the end of line"),
|
|
|
|
XDF_IGNORE_CR_AT_EOL, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F(0, "ignore-blank-lines", &options->xdl_opts,
|
|
|
|
N_("ignore changes whose lines are all blank"),
|
|
|
|
XDF_IGNORE_BLANK_LINES, PARSE_OPT_NONEG),
|
2020-10-20 14:48:09 +08:00
|
|
|
OPT_CALLBACK_F('I', "ignore-matching-lines", options, N_("<regex>"),
|
|
|
|
N_("ignore changes whose all lines match <regex>"),
|
|
|
|
0, diff_opt_ignore_regex),
|
2019-03-05 20:30:07 +08:00
|
|
|
OPT_BIT(0, "indent-heuristic", &options->xdl_opts,
|
|
|
|
N_("heuristic to shift diff hunk boundaries for easy reading"),
|
|
|
|
XDF_INDENT_HEURISTIC),
|
2019-03-05 20:30:08 +08:00
|
|
|
OPT_CALLBACK_F(0, "patience", options, NULL,
|
|
|
|
N_("generate diff using the \"patience diff\" algorithm"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_NOARG,
|
|
|
|
diff_opt_patience),
|
2019-03-05 20:30:09 +08:00
|
|
|
OPT_BITOP(0, "histogram", &options->xdl_opts,
|
|
|
|
N_("generate diff using the \"histogram diff\" algorithm"),
|
|
|
|
XDF_HISTOGRAM_DIFF, XDF_DIFF_ALGORITHM_MASK),
|
2019-03-05 20:30:10 +08:00
|
|
|
OPT_CALLBACK_F(0, "diff-algorithm", options, N_("<algorithm>"),
|
|
|
|
N_("choose a diff algorithm"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_diff_algorithm),
|
2019-03-05 20:30:11 +08:00
|
|
|
OPT_CALLBACK_F(0, "anchored", options, N_("<text>"),
|
|
|
|
N_("generate diff using the \"anchored diff\" algorithm"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_anchored),
|
2019-03-05 20:30:18 +08:00
|
|
|
OPT_CALLBACK_F(0, "word-diff", options, N_("<mode>"),
|
|
|
|
N_("show word diff, using <mode> to delimit changed words"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG, diff_opt_word_diff),
|
2019-03-05 20:30:19 +08:00
|
|
|
OPT_CALLBACK_F(0, "word-diff-regex", options, N_("<regex>"),
|
|
|
|
N_("use <regex> to decide what a word is"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_word_diff_regex),
|
2019-03-05 20:30:20 +08:00
|
|
|
OPT_CALLBACK_F(0, "color-words", options, N_("<regex>"),
|
|
|
|
N_("equivalent to --word-diff=color --word-diff-regex=<regex>"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG, diff_opt_color_words),
|
2019-03-24 16:20:09 +08:00
|
|
|
OPT_CALLBACK_F(0, "color-moved", options, N_("<mode>"),
|
2019-05-18 03:26:19 +08:00
|
|
|
N_("moved lines of code are colored differently"),
|
2019-03-24 16:20:09 +08:00
|
|
|
PARSE_OPT_OPTARG, diff_opt_color_moved),
|
2019-03-24 16:20:10 +08:00
|
|
|
OPT_CALLBACK_F(0, "color-moved-ws", options, N_("<mode>"),
|
|
|
|
N_("how white spaces are ignored in --color-moved"),
|
2019-03-24 16:20:11 +08:00
|
|
|
0, diff_opt_color_moved_ws),
|
2019-02-21 19:16:20 +08:00
|
|
|
|
2019-05-18 03:26:19 +08:00
|
|
|
OPT_GROUP(N_("Other diff options")),
|
2019-02-21 19:16:19 +08:00
|
|
|
OPT_CALLBACK_F(0, "relative", options, N_("<prefix>"),
|
|
|
|
N_("when run from subdir, exclude changes outside and show relative paths"),
|
2020-05-22 18:46:18 +08:00
|
|
|
PARSE_OPT_OPTARG,
|
2019-02-21 19:16:19 +08:00
|
|
|
diff_opt_relative),
|
2019-03-05 20:30:14 +08:00
|
|
|
OPT_BOOL('a', "text", &options->flags.text,
|
|
|
|
N_("treat all files as text")),
|
2019-03-05 20:30:15 +08:00
|
|
|
OPT_BOOL('R', NULL, &options->flags.reverse_diff,
|
|
|
|
N_("swap two inputs, reverse the diff")),
|
2019-03-05 20:30:21 +08:00
|
|
|
OPT_BOOL(0, "exit-code", &options->flags.exit_with_status,
|
|
|
|
N_("exit with 1 if there were differences, 0 otherwise")),
|
2019-03-05 20:30:22 +08:00
|
|
|
OPT_BOOL(0, "quiet", &options->flags.quick,
|
|
|
|
N_("disable all output of the program")),
|
2019-03-05 20:30:23 +08:00
|
|
|
OPT_BOOL(0, "ext-diff", &options->flags.allow_external,
|
|
|
|
N_("allow an external diff helper to be executed")),
|
2019-03-05 20:30:24 +08:00
|
|
|
OPT_CALLBACK_F(0, "textconv", options, NULL,
|
|
|
|
N_("run external text conversion filters when comparing binary files"),
|
|
|
|
PARSE_OPT_NOARG, diff_opt_textconv),
|
2019-03-05 20:30:25 +08:00
|
|
|
OPT_CALLBACK_F(0, "ignore-submodules", options, N_("<when>"),
|
|
|
|
N_("ignore changes to submodules in the diff generation"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_ignore_submodules),
|
2019-03-05 20:30:26 +08:00
|
|
|
OPT_CALLBACK_F(0, "submodule", options, N_("<format>"),
|
|
|
|
N_("specify how differences in submodules are shown"),
|
|
|
|
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
|
|
|
|
diff_opt_submodule),
|
2019-03-24 16:19:56 +08:00
|
|
|
OPT_SET_INT_F(0, "ita-invisible-in-index", &options->ita_invisible_in_index,
|
|
|
|
N_("hide 'git add -N' entries from the index"),
|
|
|
|
1, PARSE_OPT_NONEG),
|
|
|
|
OPT_SET_INT_F(0, "ita-visible-in-index", &options->ita_invisible_in_index,
|
|
|
|
N_("treat 'git add -N' entries as real in the index"),
|
|
|
|
0, PARSE_OPT_NONEG),
|
2019-03-24 16:19:59 +08:00
|
|
|
OPT_CALLBACK_F('S', NULL, options, N_("<string>"),
|
|
|
|
N_("look for differences that change the number of occurrences of the specified string"),
|
|
|
|
0, diff_opt_pickaxe_string),
|
|
|
|
OPT_CALLBACK_F('G', NULL, options, N_("<regex>"),
|
|
|
|
N_("look for differences that change the number of occurrences of the specified regex"),
|
|
|
|
0, diff_opt_pickaxe_regex),
|
2019-03-24 16:20:00 +08:00
|
|
|
OPT_BIT_F(0, "pickaxe-all", &options->pickaxe_opts,
|
|
|
|
N_("show all changes in the changeset with -S or -G"),
|
|
|
|
DIFF_PICKAXE_ALL, PARSE_OPT_NONEG),
|
|
|
|
OPT_BIT_F(0, "pickaxe-regex", &options->pickaxe_opts,
|
|
|
|
N_("treat <string> in -S as extended POSIX regular expression"),
|
|
|
|
DIFF_PICKAXE_REGEX, PARSE_OPT_NONEG),
|
2019-03-24 16:20:01 +08:00
|
|
|
OPT_FILENAME('O', NULL, &options->orderfile,
|
|
|
|
N_("control the order in which files appear in the output")),
|
diff: --{rotate,skip}-to=<path>
In the implementation of "git difftool", there is a case where the
user wants to start viewing the diffs at a specific path and
continue on to the rest, optionally wrapping around to the
beginning. Since it is somewhat cumbersome to implement such a
feature as a post-processing step of "git diff" output, let's
support it internally with two new options.
- "git diff --rotate-to=C", when the resulting patch would show
paths A B C D E without the option, would "rotate" the paths to
shows patch to C D E A B instead. It is an error when there is
no patch for C is shown.
- "git diff --skip-to=C" would instead "skip" the paths before C,
and shows patch to C D E. Again, it is an error when there is no
patch for C is shown.
- "git log [-p]" also accepts these two options, but it is not an
error if there is no change to the specified path. Instead, the
set of output paths are rotated or skipped to the specified path
or the first path that sorts after the specified path.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-12 03:57:50 +08:00
|
|
|
OPT_CALLBACK_F(0, "rotate-to", options, N_("<path>"),
|
|
|
|
N_("show the change in the specified path first"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_rotate_to),
|
|
|
|
OPT_CALLBACK_F(0, "skip-to", options, N_("<path>"),
|
|
|
|
N_("skip the output to the specified path"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_rotate_to),
|
2019-03-24 16:20:02 +08:00
|
|
|
OPT_CALLBACK_F(0, "find-object", options, N_("<object-id>"),
|
|
|
|
N_("look for differences that change the number of occurrences of the specified object"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_find_object),
|
2019-03-24 16:20:03 +08:00
|
|
|
OPT_CALLBACK_F(0, "diff-filter", options, N_("[(A|C|D|M|R|T|U|X|B)...[*]]"),
|
|
|
|
N_("select files by diff type"),
|
|
|
|
PARSE_OPT_NONEG, diff_opt_diff_filter),
|
2019-02-21 19:16:12 +08:00
|
|
|
{ OPTION_CALLBACK, 0, "output", options, N_("<file>"),
|
2022-02-23 22:27:34 +08:00
|
|
|
N_("output to a specific file"),
|
2019-02-21 19:16:12 +08:00
|
|
|
PARSE_OPT_NONEG, NULL, 0, diff_opt_output },
|
|
|
|
|
2019-01-27 08:35:31 +08:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
|
|
|
ALLOC_ARRAY(options->parseopts, ARRAY_SIZE(parseopts));
|
|
|
|
memcpy(options->parseopts, parseopts, sizeof(parseopts));
|
|
|
|
}
|
|
|
|
|
2016-01-21 19:48:44 +08:00
|
|
|
int diff_opt_parse(struct diff_options *options,
|
|
|
|
const char **av, int ac, const char *prefix)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2016-01-21 19:48:44 +08:00
|
|
|
if (!prefix)
|
|
|
|
prefix = "";
|
|
|
|
|
2019-01-27 08:35:31 +08:00
|
|
|
ac = parse_options(ac, av, prefix, options->parseopts, NULL,
|
|
|
|
PARSE_OPT_KEEP_DASHDASH |
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN |
|
|
|
|
PARSE_OPT_NO_INTERNAL_HELP |
|
|
|
|
PARSE_OPT_ONE_SHOT |
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
|
2019-03-24 16:20:10 +08:00
|
|
|
return ac;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2010-09-28 07:58:25 +08:00
|
|
|
int parse_rename_score(const char **cp_p)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
unsigned long num, scale;
|
|
|
|
int ch, dot;
|
|
|
|
const char *cp = *cp_p;
|
|
|
|
|
|
|
|
num = 0;
|
|
|
|
scale = 1;
|
|
|
|
dot = 0;
|
2009-09-01 13:35:10 +08:00
|
|
|
for (;;) {
|
2006-04-22 14:57:45 +08:00
|
|
|
ch = *cp;
|
|
|
|
if ( !dot && ch == '.' ) {
|
|
|
|
scale = 1;
|
|
|
|
dot = 1;
|
|
|
|
} else if ( ch == '%' ) {
|
|
|
|
scale = dot ? scale*100 : 100;
|
|
|
|
cp++; /* % is always at the end */
|
|
|
|
break;
|
|
|
|
} else if ( ch >= '0' && ch <= '9' ) {
|
|
|
|
if ( scale < 100000 ) {
|
|
|
|
scale *= 10;
|
|
|
|
num = (num*10) + (ch-'0');
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cp++;
|
|
|
|
}
|
|
|
|
*cp_p = cp;
|
|
|
|
|
|
|
|
/* user says num divided by scale and we say internally that
|
|
|
|
* is MAX_SCORE * num / scale.
|
|
|
|
*/
|
2007-03-07 09:44:37 +08:00
|
|
|
return (int)((num >= scale) ? MAX_SCORE : (MAX_SCORE * num / scale));
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct diff_queue_struct diff_queued_diff;
|
|
|
|
|
|
|
|
void diff_q(struct diff_queue_struct *queue, struct diff_filepair *dp)
|
|
|
|
{
|
2014-03-04 06:31:53 +08:00
|
|
|
ALLOC_GROW(queue->queue, queue->nr + 1, queue->alloc);
|
2006-04-22 14:57:45 +08:00
|
|
|
queue->queue[queue->nr++] = dp;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct diff_filepair *diff_queue(struct diff_queue_struct *queue,
|
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two)
|
|
|
|
{
|
2006-08-04 03:01:01 +08:00
|
|
|
struct diff_filepair *dp = xcalloc(1, sizeof(*dp));
|
2006-04-22 14:57:45 +08:00
|
|
|
dp->one = one;
|
|
|
|
dp->two = two;
|
|
|
|
if (queue)
|
|
|
|
diff_q(queue, dp);
|
|
|
|
return dp;
|
|
|
|
}
|
|
|
|
|
|
|
|
void diff_free_filepair(struct diff_filepair *p)
|
|
|
|
{
|
2007-10-26 02:19:10 +08:00
|
|
|
free_filespec(p->one);
|
|
|
|
free_filespec(p->two);
|
2006-04-22 14:57:45 +08:00
|
|
|
free(p);
|
|
|
|
}
|
|
|
|
|
2016-10-20 14:20:07 +08:00
|
|
|
const char *diff_aligned_abbrev(const struct object_id *oid, int len)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
int abblen;
|
|
|
|
const char *abbrev;
|
|
|
|
|
2017-12-04 05:27:42 +08:00
|
|
|
/* Do we want all 40 hex characters? */
|
2018-07-16 09:28:05 +08:00
|
|
|
if (len == the_hash_algo->hexsz)
|
2016-10-20 14:20:07 +08:00
|
|
|
return oid_to_hex(oid);
|
|
|
|
|
2017-12-04 05:27:42 +08:00
|
|
|
/* An abbreviated value is fine, possibly followed by an ellipsis. */
|
diff: handle sha1 abbreviations outside of repository
When generating diffs outside a repository (e.g., with "diff
--no-index"), we may write abbreviated sha1s as part of
"--raw" output or the "index" lines of "--patch" output.
Since we have no object database, we never find any
collisions, and these sha1s get whatever static abbreviation
length is configured (typically 7).
However, we do blindly look in ".git/objects" to see if any
objects exist, even though we know we are not in a
repository. This is usually harmless because such a
directory is unlikely to exist, but could be wrong in rare
circumstances.
Let's instead notice when we are not in a repository and
behave as if the object database is empty (i.e., just use
the default abbrev length). It would perhaps make sense to
be conservative and show full sha1s in that case, but
showing the default abbreviation is what we've always done
(and is certainly less ugly).
Note that this does mean that:
cd /not/a/repo
GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ...
used to look for collisions in /some/real/objdir but now
does not. This could be considered either a bugfix (we do
not look at objects if we have no repository) or a
regression, but it seems unlikely that anybody would care
much either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20 14:21:25 +08:00
|
|
|
abbrev = diff_abbrev_oid(oid, len);
|
2017-12-04 05:27:42 +08:00
|
|
|
|
|
|
|
if (!print_sha1_ellipsis())
|
|
|
|
return abbrev;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
abblen = strlen(abbrev);
|
2016-10-01 01:42:05 +08:00
|
|
|
|
|
|
|
/*
|
2017-12-04 05:27:42 +08:00
|
|
|
* In well-behaved cases, where the abbreviated result is the
|
2016-10-01 01:42:05 +08:00
|
|
|
* same as the requested length, append three dots after the
|
|
|
|
* abbreviation (hence the whole logic is limited to the case
|
|
|
|
* where abblen < 37); when the actual abbreviated result is a
|
|
|
|
* bit longer than the requested length, we reduce the number
|
|
|
|
* of dots so that they match the well-behaved ones. However,
|
|
|
|
* if the actual abbreviation is longer than the requested
|
|
|
|
* length by more than three, we give up on aligning, and add
|
|
|
|
* three dots anyway, to indicate that the output is not the
|
|
|
|
* full object name. Yes, this may be suboptimal, but this
|
|
|
|
* appears only in "diff --raw --abbrev" output and it is not
|
|
|
|
* worth the effort to change it now. Note that this would
|
|
|
|
* likely to work fine when the automatic sizing of default
|
|
|
|
* abbreviation length is used--we would be fed -1 in "len" in
|
|
|
|
* that case, and will end up always appending three-dots, but
|
|
|
|
* the automatic sizing is supposed to give abblen that ensures
|
|
|
|
* uniqueness across all objects (statistically speaking).
|
|
|
|
*/
|
2018-07-16 09:28:05 +08:00
|
|
|
if (abblen < the_hash_algo->hexsz - 3) {
|
2017-03-27 00:01:24 +08:00
|
|
|
static char hex[GIT_MAX_HEXSZ + 1];
|
2006-04-22 14:57:45 +08:00
|
|
|
if (len < abblen && abblen <= len + 2)
|
2015-09-25 05:06:08 +08:00
|
|
|
xsnprintf(hex, sizeof(hex), "%s%.*s", abbrev, len+3-abblen, "..");
|
2006-04-22 14:57:45 +08:00
|
|
|
else
|
2015-09-25 05:06:08 +08:00
|
|
|
xsnprintf(hex, sizeof(hex), "%s...", abbrev);
|
2006-04-22 14:57:45 +08:00
|
|
|
return hex;
|
|
|
|
}
|
2016-10-20 14:20:07 +08:00
|
|
|
|
|
|
|
return oid_to_hex(oid);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
static void diff_flush_raw(struct diff_filepair *p, struct diff_options *opt)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
int line_termination = opt->line_termination;
|
|
|
|
int inter_name_termination = line_termination ? '\t' : '\0';
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2013-02-08 04:15:27 +08:00
|
|
|
fprintf(opt->file, "%s", diff_line_prefix(opt));
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
if (!(opt->output_format & DIFF_FORMAT_NAME_STATUS)) {
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(opt->file, ":%06o %06o %s ", p->one->mode, p->two->mode,
|
2016-10-20 14:20:07 +08:00
|
|
|
diff_aligned_abbrev(&p->one->oid, opt->abbrev));
|
2016-06-25 07:09:23 +08:00
|
|
|
fprintf(opt->file, "%s ",
|
2016-10-20 14:20:07 +08:00
|
|
|
diff_aligned_abbrev(&p->two->oid, opt->abbrev));
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
if (p->score) {
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(opt->file, "%c%03d%c", p->status, similarity_index(p),
|
|
|
|
inter_name_termination);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
} else {
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(opt->file, "%c%c", p->status, inter_name_termination);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
if (p->status == DIFF_STATUS_COPIED ||
|
|
|
|
p->status == DIFF_STATUS_RENAMED) {
|
|
|
|
const char *name_a, *name_b;
|
|
|
|
name_a = p->one->path;
|
|
|
|
name_b = p->two->path;
|
|
|
|
strip_prefix(opt->prefix_length, &name_a, &name_b);
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(name_a, opt->file, inter_name_termination);
|
|
|
|
write_name_quoted(name_b, opt->file, line_termination);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
} else {
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
const char *name_a, *name_b;
|
|
|
|
name_a = p->one->mode ? p->one->path : p->two->path;
|
|
|
|
name_b = NULL;
|
|
|
|
strip_prefix(opt->prefix_length, &name_a, &name_b);
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(name_a, opt->file, line_termination);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int diff_unmodified_pair(struct diff_filepair *p)
|
|
|
|
{
|
|
|
|
/* This function is written stricter than necessary to support
|
|
|
|
* the currently implemented transformers, but the idea is to
|
|
|
|
* let transformers to produce diff_filepairs any way they want,
|
|
|
|
* and filter and clean them up here before producing the output.
|
|
|
|
*/
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
struct diff_filespec *one = p->one, *two = p->two;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (DIFF_PAIR_UNMERGED(p))
|
|
|
|
return 0; /* unmerged is interesting */
|
|
|
|
|
|
|
|
/* deletion, addition, mode or type change
|
|
|
|
* and rename are all interesting.
|
|
|
|
*/
|
|
|
|
if (DIFF_FILE_VALID(one) != DIFF_FILE_VALID(two) ||
|
|
|
|
DIFF_PAIR_MODE_CHANGED(p) ||
|
|
|
|
strcmp(one->path, two->path))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* both are valid and point at the same path. that is, we are
|
|
|
|
* dealing with a change.
|
|
|
|
*/
|
2016-06-25 07:09:24 +08:00
|
|
|
if (one->oid_valid && two->oid_valid &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
oideq(&one->oid, &two->oid) &&
|
2010-03-13 05:23:52 +08:00
|
|
|
!one->dirty_submodule && !two->dirty_submodule)
|
2006-04-22 14:57:45 +08:00
|
|
|
return 1; /* no change */
|
2016-06-25 07:09:24 +08:00
|
|
|
if (!one->oid_valid && !two->oid_valid)
|
2006-04-22 14:57:45 +08:00
|
|
|
return 1; /* both look at the same file on the filesystem. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void diff_flush_patch(struct diff_filepair *p, struct diff_options *o)
|
|
|
|
{
|
2022-02-02 10:37:34 +08:00
|
|
|
int include_conflict_headers =
|
|
|
|
(additional_headers(o, p->one->path) &&
|
|
|
|
(!o->filter || filter_bit_tst(DIFF_STATUS_UNMERGED, o)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if we can return early without showing a diff. Note that
|
|
|
|
* diff_filepair only stores {oid, path, mode, is_valid}
|
|
|
|
* information for each path, and thus diff_unmodified_pair() only
|
|
|
|
* considers those bits of info. However, we do not want pairs
|
|
|
|
* created by create_filepairs_for_header_only_notifications()
|
|
|
|
* (which always look like unmodified pairs) to be ignored, so
|
|
|
|
* return early if both p is unmodified AND we don't want to
|
|
|
|
* include_conflict_headers.
|
|
|
|
*/
|
|
|
|
if (diff_unmodified_pair(p) && !include_conflict_headers)
|
2006-04-22 14:57:45 +08:00
|
|
|
return;
|
|
|
|
|
2022-02-02 10:37:34 +08:00
|
|
|
/* Actually, we can also return early to avoid showing tree diffs */
|
2006-04-22 14:57:45 +08:00
|
|
|
if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
|
|
|
|
(DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
|
2022-02-02 10:37:34 +08:00
|
|
|
return;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
run_diff(p, o);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void diff_flush_stat(struct diff_filepair *p, struct diff_options *o,
|
|
|
|
struct diffstat_t *diffstat)
|
|
|
|
{
|
|
|
|
if (diff_unmodified_pair(p))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
|
|
|
|
(DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
|
2010-10-25 05:03:10 +08:00
|
|
|
return; /* no useful stat for tree diffs */
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
run_diffstat(p, o, diffstat);
|
|
|
|
}
|
|
|
|
|
2006-05-21 05:43:13 +08:00
|
|
|
static void diff_flush_checkdiff(struct diff_filepair *p,
|
|
|
|
struct diff_options *o)
|
|
|
|
{
|
|
|
|
if (diff_unmodified_pair(p))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
|
|
|
|
(DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
|
2010-10-25 05:03:10 +08:00
|
|
|
return; /* nothing to check in tree diffs */
|
2006-05-21 05:43:13 +08:00
|
|
|
|
|
|
|
run_checkdiff(p, o);
|
|
|
|
}
|
|
|
|
|
2022-02-02 10:37:34 +08:00
|
|
|
int diff_queue_is_empty(struct diff_options *o)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
2022-02-02 10:37:34 +08:00
|
|
|
int include_conflict_headers =
|
|
|
|
(o->additional_path_headers &&
|
|
|
|
(!o->filter || filter_bit_tst(DIFF_STATUS_UNMERGED, o)));
|
|
|
|
|
|
|
|
if (include_conflict_headers)
|
|
|
|
return 0;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
for (i = 0; i < q->nr; i++)
|
|
|
|
if (!diff_unmodified_pair(q->queue[i]))
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if DIFF_DEBUG
|
|
|
|
void diff_debug_filespec(struct diff_filespec *s, int x, const char *one)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "queue[%d] %s (%s) %s %06o %s\n",
|
|
|
|
x, one ? one : "",
|
|
|
|
s->path,
|
|
|
|
DIFF_FILE_VALID(s) ? "valid" : "invalid",
|
|
|
|
s->mode,
|
2016-06-25 07:09:24 +08:00
|
|
|
s->oid_valid ? oid_to_hex(&s->oid) : "");
|
2014-01-17 09:21:59 +08:00
|
|
|
fprintf(stderr, "queue[%d] %s size %lu\n",
|
2006-04-22 14:57:45 +08:00
|
|
|
x, one ? one : "",
|
2014-01-17 09:21:59 +08:00
|
|
|
s->size);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_debug_filepair(const struct diff_filepair *p, int i)
|
|
|
|
{
|
|
|
|
diff_debug_filespec(p->one, i, "one");
|
|
|
|
diff_debug_filespec(p->two, i, "two");
|
2007-10-26 02:20:56 +08:00
|
|
|
fprintf(stderr, "score %d, status %c rename_used %d broken %d\n",
|
2006-04-22 14:57:45 +08:00
|
|
|
p->score, p->status ? p->status : '?',
|
2007-10-26 02:20:56 +08:00
|
|
|
p->one->rename_used, p->broken_pair);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_debug_queue(const char *msg, struct diff_queue_struct *q)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
if (msg)
|
|
|
|
fprintf(stderr, "%s\n", msg);
|
|
|
|
fprintf(stderr, "q->nr = %d\n", q->nr);
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
diff_debug_filepair(p, i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static void diff_resolve_rename_copy(void)
|
|
|
|
{
|
2007-10-26 02:20:56 +08:00
|
|
|
int i;
|
|
|
|
struct diff_filepair *p;
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
|
|
|
|
diff_debug_queue("resolve-rename-copy", q);
|
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
p = q->queue[i];
|
|
|
|
p->status = 0; /* undecided */
|
|
|
|
if (DIFF_PAIR_UNMERGED(p))
|
|
|
|
p->status = DIFF_STATUS_UNMERGED;
|
|
|
|
else if (!DIFF_FILE_VALID(p->one))
|
|
|
|
p->status = DIFF_STATUS_ADDED;
|
|
|
|
else if (!DIFF_FILE_VALID(p->two))
|
|
|
|
p->status = DIFF_STATUS_DELETED;
|
|
|
|
else if (DIFF_PAIR_TYPE_CHANGED(p))
|
|
|
|
p->status = DIFF_STATUS_TYPE_CHANGED;
|
|
|
|
|
|
|
|
/* from this point on, we are dealing with a pair
|
|
|
|
* whose both sides are valid and of the same type, i.e.
|
|
|
|
* either in-place edit or rename/copy edit.
|
|
|
|
*/
|
|
|
|
else if (DIFF_PAIR_RENAME(p)) {
|
2007-10-26 02:20:56 +08:00
|
|
|
/*
|
|
|
|
* A rename might have re-connected a broken
|
|
|
|
* pair up, causing the pathnames to be the
|
|
|
|
* same again. If so, that's not a rename at
|
|
|
|
* all, just a modification..
|
|
|
|
*
|
|
|
|
* Otherwise, see if this source was used for
|
|
|
|
* multiple renames, in which case we decrement
|
|
|
|
* the count, and call it a copy.
|
2006-04-22 14:57:45 +08:00
|
|
|
*/
|
2007-10-26 02:20:56 +08:00
|
|
|
if (!strcmp(p->one->path, p->two->path))
|
|
|
|
p->status = DIFF_STATUS_MODIFIED;
|
|
|
|
else if (--p->one->rename_used > 0)
|
2006-04-22 14:57:45 +08:00
|
|
|
p->status = DIFF_STATUS_COPIED;
|
2007-10-26 02:20:56 +08:00
|
|
|
else
|
2006-04-22 14:57:45 +08:00
|
|
|
p->status = DIFF_STATUS_RENAMED;
|
|
|
|
}
|
2018-08-29 05:22:48 +08:00
|
|
|
else if (!oideq(&p->one->oid, &p->two->oid) ||
|
2007-02-23 04:50:10 +08:00
|
|
|
p->one->mode != p->two->mode ||
|
2010-03-13 05:23:52 +08:00
|
|
|
p->one->dirty_submodule ||
|
|
|
|
p->two->dirty_submodule ||
|
2016-06-25 07:09:23 +08:00
|
|
|
is_null_oid(&p->one->oid))
|
2006-04-22 14:57:45 +08:00
|
|
|
p->status = DIFF_STATUS_MODIFIED;
|
|
|
|
else {
|
|
|
|
/* This is a "no-change" entry and should not
|
|
|
|
* happen anymore, but prepare for broken callers.
|
|
|
|
*/
|
|
|
|
error("feeding unmodified %s to diffcore",
|
|
|
|
p->one->path);
|
|
|
|
p->status = DIFF_STATUS_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
diff_debug_queue("resolve-rename-copy done", q);
|
|
|
|
}
|
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
static int check_pair_status(struct diff_filepair *p)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
switch (p->status) {
|
|
|
|
case DIFF_STATUS_UNKNOWN:
|
2006-06-25 01:21:53 +08:00
|
|
|
return 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
case 0:
|
|
|
|
die("internal error in diff-resolve-rename-copy");
|
|
|
|
default:
|
2006-06-25 01:21:53 +08:00
|
|
|
return 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
static void flush_one_pair(struct diff_filepair *p, struct diff_options *opt)
|
|
|
|
{
|
|
|
|
int fmt = opt->output_format;
|
|
|
|
|
|
|
|
if (fmt & DIFF_FORMAT_CHECKDIFF)
|
|
|
|
diff_flush_checkdiff(p, opt);
|
|
|
|
else if (fmt & (DIFF_FORMAT_RAW | DIFF_FORMAT_NAME_STATUS))
|
|
|
|
diff_flush_raw(p, opt);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
else if (fmt & DIFF_FORMAT_NAME) {
|
|
|
|
const char *name_a, *name_b;
|
|
|
|
name_a = p->two->path;
|
|
|
|
name_b = NULL;
|
|
|
|
strip_prefix(opt->prefix_length, &name_a, &name_b);
|
2017-02-09 04:31:15 +08:00
|
|
|
fprintf(opt->file, "%s", diff_line_prefix(opt));
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(name_a, opt->file, opt->line_termination);
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
}
|
2006-06-25 01:21:53 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:05 +08:00
|
|
|
static void show_file_mode_name(struct diff_options *opt, const char *newdelete, struct diff_filespec *fs)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
2017-06-30 08:07:05 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2006-05-14 20:13:49 +08:00
|
|
|
if (fs->mode)
|
2017-06-30 08:07:05 +08:00
|
|
|
strbuf_addf(&sb, " %s mode %06o ", newdelete, fs->mode);
|
2006-05-14 20:13:49 +08:00
|
|
|
else
|
2017-06-30 08:07:05 +08:00
|
|
|
strbuf_addf(&sb, " %s ", newdelete);
|
2006-05-14 20:13:49 +08:00
|
|
|
|
2017-06-30 08:07:05 +08:00
|
|
|
quote_c_style(fs->path, &sb, NULL, 0);
|
|
|
|
strbuf_addch(&sb, '\n');
|
|
|
|
emit_diff_symbol(opt, DIFF_SYMBOL_SUMMARY,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
2006-05-14 20:13:49 +08:00
|
|
|
|
2017-06-30 08:07:05 +08:00
|
|
|
static void show_mode_change(struct diff_options *opt, struct diff_filepair *p,
|
|
|
|
int show_name)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
|
|
|
if (p->one->mode && p->two->mode && p->one->mode != p->two->mode) {
|
2017-06-30 08:07:05 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
strbuf_addf(&sb, " mode change %06o => %06o",
|
|
|
|
p->one->mode, p->two->mode);
|
2007-02-10 22:37:48 +08:00
|
|
|
if (show_name) {
|
2017-06-30 08:07:05 +08:00
|
|
|
strbuf_addch(&sb, ' ');
|
|
|
|
quote_c_style(p->two->path, &sb, NULL, 0);
|
2007-02-10 22:37:48 +08:00
|
|
|
}
|
2017-09-28 06:51:26 +08:00
|
|
|
strbuf_addch(&sb, '\n');
|
2017-06-30 08:07:05 +08:00
|
|
|
emit_diff_symbol(opt, DIFF_SYMBOL_SUMMARY,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
strbuf_release(&sb);
|
2006-05-14 20:13:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:05 +08:00
|
|
|
static void show_rename_copy(struct diff_options *opt, const char *renamecopy,
|
|
|
|
struct diff_filepair *p)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
2017-06-30 08:07:05 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2018-02-01 21:02:20 +08:00
|
|
|
struct strbuf names = STRBUF_INIT;
|
|
|
|
|
|
|
|
pprint_rename(&names, p->one->path, p->two->path);
|
2017-06-30 08:07:05 +08:00
|
|
|
strbuf_addf(&sb, " %s %s (%d%%)\n",
|
2018-02-01 21:02:20 +08:00
|
|
|
renamecopy, names.buf, similarity_index(p));
|
|
|
|
strbuf_release(&names);
|
2017-06-30 08:07:05 +08:00
|
|
|
emit_diff_symbol(opt, DIFF_SYMBOL_SUMMARY,
|
|
|
|
sb.buf, sb.len, 0);
|
|
|
|
show_mode_change(opt, p, 0);
|
2017-08-31 01:49:42 +08:00
|
|
|
strbuf_release(&sb);
|
2006-05-14 20:13:49 +08:00
|
|
|
}
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static void diff_summary(struct diff_options *opt, struct diff_filepair *p)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
|
|
|
switch(p->status) {
|
|
|
|
case DIFF_STATUS_DELETED:
|
2017-06-30 08:07:05 +08:00
|
|
|
show_file_mode_name(opt, "delete", p->one);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_ADDED:
|
2017-06-30 08:07:05 +08:00
|
|
|
show_file_mode_name(opt, "create", p->two);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_COPIED:
|
2017-06-30 08:07:05 +08:00
|
|
|
show_rename_copy(opt, "copy", p);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_RENAMED:
|
2017-06-30 08:07:05 +08:00
|
|
|
show_rename_copy(opt, "rename", p);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (p->score) {
|
2017-06-30 08:07:05 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
strbuf_addstr(&sb, " rewrite ");
|
|
|
|
quote_c_style(p->two->path, &sb, NULL, 0);
|
|
|
|
strbuf_addf(&sb, " (%d%%)\n", similarity_index(p));
|
|
|
|
emit_diff_symbol(opt, DIFF_SYMBOL_SUMMARY,
|
|
|
|
sb.buf, sb.len, 0);
|
2017-08-31 01:49:41 +08:00
|
|
|
strbuf_release(&sb);
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
}
|
2017-06-30 08:07:05 +08:00
|
|
|
show_mode_change(opt, p, !p->score);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-25 09:51:08 +08:00
|
|
|
struct patch_id_t {
|
2019-08-19 04:04:03 +08:00
|
|
|
git_hash_ctx *ctx;
|
2006-06-25 09:51:08 +08:00
|
|
|
int patchlen;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int remove_space(char *line, int len)
|
|
|
|
{
|
|
|
|
int i;
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
char *dst = line;
|
|
|
|
unsigned char c;
|
2006-06-25 09:51:08 +08:00
|
|
|
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
for (i = 0; i < len; i++)
|
|
|
|
if (!isspace((c = line[i])))
|
|
|
|
*dst++ = c;
|
2006-06-25 09:51:08 +08:00
|
|
|
|
Full rework of quote_c_style and write_name_quoted.
* quote_c_style works on a strbuf instead of a wild buffer.
* quote_c_style is now clever enough to not add double quotes if not needed.
* write_name_quoted inherits those advantages, but also take a different
set of arguments. Now instead of asking for quotes or not, you pass a
"terminator". If it's \0 then we assume you don't want to escape, else C
escaping is performed. In any case, the terminator is also appended to the
stream. It also no longer takes the prefix/prefix_len arguments, as it's
seldomly used, and makes some optimizations harder.
* write_name_quotedpfx is created to work like write_name_quoted and take
the prefix/prefix_len arguments.
Thanks to those API changes, diff.c has somehow lost weight, thanks to the
removal of functions that were wrappers around the old write_name_quoted
trying to give it a semantics like the new one, but performing a lot of
allocations for this goal. Now we always write directly to the stream, no
intermediate allocation is performed.
As a side effect of the refactor in builtin-apply.c, the length of the bar
graphs in diffstats are not affected anymore by the fact that the path was
clipped.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20 06:42:15 +08:00
|
|
|
return dst - line;
|
2006-06-25 09:51:08 +08:00
|
|
|
}
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
void flush_one_hunk(struct object_id *result, git_hash_ctx *ctx)
|
2019-04-27 07:51:57 +08:00
|
|
|
{
|
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
|
|
|
unsigned short carry = 0;
|
|
|
|
int i;
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->final_fn(hash, ctx);
|
|
|
|
the_hash_algo->init_fn(ctx);
|
2019-04-27 07:51:57 +08:00
|
|
|
/* 20-byte sum, with carry */
|
2019-08-19 04:04:03 +08:00
|
|
|
for (i = 0; i < the_hash_algo->rawsz; ++i) {
|
2019-04-27 07:51:57 +08:00
|
|
|
carry += result->hash[i] + hash[i];
|
|
|
|
result->hash[i] = carry;
|
|
|
|
carry >>= 8;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-13 01:15:24 +08:00
|
|
|
static int patch_id_consume(void *priv, char *line, unsigned long len)
|
2006-06-25 09:51:08 +08:00
|
|
|
{
|
|
|
|
struct patch_id_t *data = priv;
|
|
|
|
int new_len;
|
|
|
|
|
2020-08-19 06:08:54 +08:00
|
|
|
if (len > 12 && starts_with(line, "\\ "))
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-06-25 09:51:08 +08:00
|
|
|
new_len = remove_space(line, len);
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(data->ctx, line, new_len);
|
2006-06-25 09:51:08 +08:00
|
|
|
data->patchlen += new_len;
|
2021-04-13 01:15:24 +08:00
|
|
|
return 0;
|
2006-06-25 09:51:08 +08:00
|
|
|
}
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
static void patch_id_add_string(git_hash_ctx *ctx, const char *str)
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
{
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(ctx, str, strlen(str));
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
}
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
static void patch_id_add_mode(git_hash_ctx *ctx, unsigned mode)
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
{
|
|
|
|
/* large enough for 2^32 in octal */
|
|
|
|
char buf[12];
|
|
|
|
int len = xsnprintf(buf, sizeof(buf), "%06o", mode);
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(ctx, buf, len);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
}
|
|
|
|
|
2019-04-27 07:51:57 +08:00
|
|
|
/* returns 0 upon success, and writes result into oid */
|
|
|
|
static int diff_get_patch_id(struct diff_options *options, struct object_id *oid, int diff_header_only, int stable)
|
2006-06-25 09:51:08 +08:00
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
2019-08-19 04:04:03 +08:00
|
|
|
git_hash_ctx ctx;
|
2006-06-25 09:51:08 +08:00
|
|
|
struct patch_id_t data;
|
|
|
|
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->init_fn(&ctx);
|
2006-06-25 09:51:08 +08:00
|
|
|
memset(&data, 0, sizeof(struct patch_id_t));
|
|
|
|
data.ctx = &ctx;
|
2019-04-27 07:51:57 +08:00
|
|
|
oidclr(oid);
|
2006-06-25 09:51:08 +08:00
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
int len1, len2;
|
|
|
|
|
2008-10-25 21:30:37 +08:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-05 02:05:46 +08:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-25 09:51:08 +08:00
|
|
|
if (p->status == 0)
|
|
|
|
return error("internal diff status error");
|
|
|
|
if (p->status == DIFF_STATUS_UNKNOWN)
|
|
|
|
continue;
|
|
|
|
if (diff_unmodified_pair(p))
|
|
|
|
continue;
|
|
|
|
if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
|
|
|
|
(DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
|
|
|
|
continue;
|
|
|
|
if (DIFF_PAIR_UNMERGED(p))
|
|
|
|
continue;
|
|
|
|
|
2018-09-21 23:57:31 +08:00
|
|
|
diff_fill_oid_info(p->one, options->repo->index);
|
|
|
|
diff_fill_oid_info(p->two, options->repo->index);
|
2006-06-25 09:51:08 +08:00
|
|
|
|
|
|
|
len1 = remove_space(p->one->path, strlen(p->one->path));
|
|
|
|
len2 = remove_space(p->two->path, strlen(p->two->path));
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
patch_id_add_string(&ctx, "diff--git");
|
|
|
|
patch_id_add_string(&ctx, "a/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->one->path, len1);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
patch_id_add_string(&ctx, "b/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->two->path, len2);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
|
|
|
|
if (p->one->mode == 0) {
|
|
|
|
patch_id_add_string(&ctx, "newfilemode");
|
|
|
|
patch_id_add_mode(&ctx, p->two->mode);
|
|
|
|
patch_id_add_string(&ctx, "---/dev/null");
|
|
|
|
patch_id_add_string(&ctx, "+++b/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->two->path, len2);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
} else if (p->two->mode == 0) {
|
|
|
|
patch_id_add_string(&ctx, "deletedfilemode");
|
|
|
|
patch_id_add_mode(&ctx, p->one->mode);
|
|
|
|
patch_id_add_string(&ctx, "---a/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->one->path, len1);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
patch_id_add_string(&ctx, "+++/dev/null");
|
|
|
|
} else {
|
|
|
|
patch_id_add_string(&ctx, "---a/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->one->path, len1);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
patch_id_add_string(&ctx, "+++b/");
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, p->two->path, len2);
|
diff: avoid fixed-size buffer for patch-ids
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accommodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_MAX. The
static value may not be a real limit on the current
filesystem. Moreover, we may compute patch-ids for
names stored only in git, without touching the current
filesystem at all.
2. The 20 bytes is not nearly enough to cover the
extra content we put in the buffer.
As a result, the data we feed to the sha1 computation may be
truncated, and it's possible that a commit with a very long
filename could erroneously collide in the patch-id space
with another commit. For instance, if one commit modified
"really-long-filename/foo" and another modified "bar" in the
same directory.
In practice this is unlikely. Because the filenames are
repeated, and because there's a single cutoff at the end of
the buffer, the offending filename would have to be on the
order of four times larger than PATH_MAX.
We could fix this by moving to a strbuf. However, we can
observe that the purpose of formatting this in the first
place is to feed it to git_SHA1_Update(). So instead, let's
just feed each part of the formatted string directly. This
actually ends up more readable, and we can even factor out
some duplicated bits from the various conditional branches.
Technically this may change the output of patch-id for very
long filenames, but it's not worth making an exception for
this in the --stable output. It was a bug, and one that only
affected an unlikely set of paths. And anyway, the exact
value would have varied from platform to platform depending
on the value of PATH_MAX, so there is no "stable" value.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31 02:26:05 +08:00
|
|
|
}
|
2006-06-25 09:51:08 +08:00
|
|
|
|
2016-07-30 00:19:19 +08:00
|
|
|
if (diff_header_only)
|
|
|
|
continue;
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (fill_mmfile(options->repo, &mf1, p->one) < 0 ||
|
|
|
|
fill_mmfile(options->repo, &mf2, p->two) < 0)
|
2016-07-30 00:19:19 +08:00
|
|
|
return error("unable to read files to diff");
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (diff_filespec_is_binary(options->repo, p->one) ||
|
|
|
|
diff_filespec_is_binary(options->repo, p->two)) {
|
2019-08-19 04:04:03 +08:00
|
|
|
the_hash_algo->update_fn(&ctx, oid_to_hex(&p->one->oid),
|
|
|
|
the_hash_algo->hexsz);
|
|
|
|
the_hash_algo->update_fn(&ctx, oid_to_hex(&p->two->oid),
|
|
|
|
the_hash_algo->hexsz);
|
2010-08-15 15:20:43 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = 0;
|
2006-06-25 09:51:08 +08:00
|
|
|
xecfg.ctxlen = 3;
|
2021-04-13 01:15:29 +08:00
|
|
|
xecfg.flags = XDL_EMIT_NO_HUNK_HDR;
|
|
|
|
if (xdi_diff_outf(&mf1, &mf2, NULL,
|
2018-11-02 14:36:36 +08:00
|
|
|
patch_id_consume, &data, &xpp, &xecfg))
|
react to errors in xdi_diff
When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).
In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.
Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.
We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).
There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25 07:12:23 +08:00
|
|
|
return error("unable to generate patch-id diff for %s",
|
|
|
|
p->one->path);
|
2019-04-27 07:51:57 +08:00
|
|
|
|
|
|
|
if (stable)
|
|
|
|
flush_one_hunk(oid, &ctx);
|
2006-06-25 09:51:08 +08:00
|
|
|
}
|
|
|
|
|
2019-04-27 07:51:57 +08:00
|
|
|
if (!stable)
|
2021-04-26 09:02:53 +08:00
|
|
|
the_hash_algo->final_oid_fn(oid, &ctx);
|
2019-04-27 07:51:57 +08:00
|
|
|
|
2006-06-25 09:51:08 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-04-27 07:51:57 +08:00
|
|
|
int diff_flush_patch_id(struct diff_options *options, struct object_id *oid, int diff_header_only, int stable)
|
2006-06-25 09:51:08 +08:00
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
2019-04-27 07:51:57 +08:00
|
|
|
int result = diff_get_patch_id(options, oid, diff_header_only, stable);
|
2006-06-25 09:51:08 +08:00
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++)
|
|
|
|
diff_free_filepair(q->queue[i]);
|
|
|
|
|
|
|
|
free(q->queue);
|
2010-05-07 12:52:27 +08:00
|
|
|
DIFF_QUEUE_CLEAR(q);
|
2006-06-25 09:51:08 +08:00
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2006-06-27 20:09:17 +08:00
|
|
|
static int is_summary_empty(const struct diff_queue_struct *q)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2006-06-27 20:09:17 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
const struct diff_filepair *p = q->queue[i];
|
|
|
|
|
|
|
|
switch (p->status) {
|
|
|
|
case DIFF_STATUS_DELETED:
|
|
|
|
case DIFF_STATUS_ADDED:
|
|
|
|
case DIFF_STATUS_COPIED:
|
|
|
|
case DIFF_STATUS_RENAMED:
|
|
|
|
return 0;
|
|
|
|
default:
|
|
|
|
if (p->score)
|
|
|
|
return 0;
|
|
|
|
if (p->one->mode && p->two->mode &&
|
|
|
|
p->one->mode != p->two->mode)
|
|
|
|
return 0;
|
|
|
|
break;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2006-06-27 20:09:17 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-01-07 05:50:06 +08:00
|
|
|
static const char rename_limit_warning[] =
|
2021-07-15 08:45:21 +08:00
|
|
|
N_("exhaustive rename detection was skipped due to too many files.");
|
2011-01-07 05:50:06 +08:00
|
|
|
|
|
|
|
static const char degrade_cc_to_c_warning[] =
|
2016-10-17 21:15:29 +08:00
|
|
|
N_("only found copies from modified paths due to too many files.");
|
2011-01-07 05:50:06 +08:00
|
|
|
|
|
|
|
static const char rename_limit_advice[] =
|
2016-10-17 21:15:29 +08:00
|
|
|
N_("you may want to set your %s variable to at least "
|
|
|
|
"%d and retry the command.");
|
2011-01-07 05:50:06 +08:00
|
|
|
|
|
|
|
void diff_warn_rename_limit(const char *varname, int needed, int degraded_cc)
|
|
|
|
{
|
2018-01-16 17:23:49 +08:00
|
|
|
fflush(stdout);
|
2011-01-07 05:50:06 +08:00
|
|
|
if (degraded_cc)
|
2016-10-17 21:15:29 +08:00
|
|
|
warning(_(degrade_cc_to_c_warning));
|
2011-01-07 05:50:06 +08:00
|
|
|
else if (needed)
|
2016-10-17 21:15:29 +08:00
|
|
|
warning(_(rename_limit_warning));
|
2011-01-07 05:50:06 +08:00
|
|
|
else
|
|
|
|
return;
|
2017-11-14 04:15:59 +08:00
|
|
|
if (0 < needed)
|
2016-10-17 21:15:29 +08:00
|
|
|
warning(_(rename_limit_advice), varname, needed);
|
2011-01-07 05:50:06 +08:00
|
|
|
}
|
|
|
|
|
2022-02-02 10:37:34 +08:00
|
|
|
static void create_filepairs_for_header_only_notifications(struct diff_options *o)
|
|
|
|
{
|
|
|
|
struct strset present;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
struct hashmap_iter iter;
|
|
|
|
struct strmap_entry *e;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
strset_init_with_options(&present, /*pool*/ NULL, /*strdup*/ 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find out which paths exist in diff_queued_diff, preferring
|
|
|
|
* one->path for any pair that has multiple paths.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
char *path = p->one->path ? p->one->path : p->two->path;
|
|
|
|
|
|
|
|
if (strmap_contains(o->additional_path_headers, path))
|
|
|
|
strset_add(&present, path);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Loop over paths in additional_path_headers; for each NOT already
|
|
|
|
* in diff_queued_diff, create a synthetic filepair and insert that
|
|
|
|
* into diff_queued_diff.
|
|
|
|
*/
|
|
|
|
strmap_for_each_entry(o->additional_path_headers, &iter, e) {
|
|
|
|
if (!strset_contains(&present, e->key)) {
|
|
|
|
struct diff_filespec *one, *two;
|
|
|
|
struct diff_filepair *p;
|
|
|
|
|
|
|
|
one = alloc_filespec(e->key);
|
|
|
|
two = alloc_filespec(e->key);
|
|
|
|
fill_filespec(one, null_oid(), 0, 0);
|
|
|
|
fill_filespec(two, null_oid(), 0, 0);
|
|
|
|
p = diff_queue(q, one, two);
|
|
|
|
p->status = DIFF_STATUS_MODIFIED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Re-sort the filepairs */
|
|
|
|
diffcore_fix_diff_index();
|
|
|
|
|
|
|
|
/* Cleanup */
|
|
|
|
strset_clear(&present);
|
|
|
|
}
|
|
|
|
|
2017-06-30 08:06:48 +08:00
|
|
|
static void diff_flush_patch_all_file_pairs(struct diff_options *o)
|
|
|
|
{
|
|
|
|
int i;
|
2017-06-30 08:07:06 +08:00
|
|
|
static struct emitted_diff_symbols esm = EMITTED_DIFF_SYMBOLS_INIT;
|
2017-06-30 08:06:48 +08:00
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2017-06-30 08:06:53 +08:00
|
|
|
|
|
|
|
if (WSEH_NEW & WS_RULE_MASK)
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("WS rules bit mask overlaps with diff symbol flags");
|
2017-06-30 08:06:53 +08:00
|
|
|
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
if (o->color_moved)
|
|
|
|
o->emitted_symbols = &esm;
|
2017-06-30 08:07:06 +08:00
|
|
|
|
2022-02-02 10:37:34 +08:00
|
|
|
if (o->additional_path_headers)
|
|
|
|
create_filepairs_for_header_only_notifications(o);
|
|
|
|
|
2017-06-30 08:06:48 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
if (check_pair_status(p))
|
|
|
|
diff_flush_patch(p, o);
|
|
|
|
}
|
2017-06-30 08:07:06 +08:00
|
|
|
|
|
|
|
if (o->emitted_symbols) {
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
if (o->color_moved) {
|
2021-12-09 18:30:09 +08:00
|
|
|
struct mem_pool entry_pool;
|
|
|
|
struct moved_entry_list *entry_list;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
mem_pool_init(&entry_pool, 1024 * 1024);
|
|
|
|
entry_list = add_lines_to_move_detection(o,
|
|
|
|
&entry_pool);
|
|
|
|
mark_color_as_moved(o, entry_list);
|
2017-07-01 04:53:09 +08:00
|
|
|
if (o->color_moved == COLOR_MOVED_ZEBRA_DIM)
|
|
|
|
dim_moved_lines(o);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
|
2021-12-09 18:30:09 +08:00
|
|
|
mem_pool_discard(&entry_pool, 0);
|
|
|
|
free(entry_list);
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:07:06 +08:00
|
|
|
for (i = 0; i < esm.nr; i++)
|
|
|
|
emit_diff_symbol_from_struct(o, &esm.buf[i]);
|
|
|
|
|
|
|
|
for (i = 0; i < esm.nr; i++)
|
|
|
|
free((void *)esm.buf[i].line);
|
diff: clear emitted_symbols flag after use
There's an odd bug when "log --color-moved" is used with the combination
of "--cc --stat -p": the stat for merge commits is erroneously shown
with the diff of the _next_ commit.
The included test demonstrates the issue. Our history looks something
like this:
A-B-M--D
\ /
C
When we run "git log --cc --stat -p --color-moved" starting at D, we get
this sequence of events:
1. The diff for D is using -p, so diff_flush() calls into
diff_flush_patch_all_file_pairs(). There we see that o->color_moved
is in effect, so we point o->emitted_symbols to a static local
struct, causing diff_flush_patch() to queue the symbols instead of
actually writing them out.
We then do our move detection, emit the symbols, and clear the
struct. But we leave o->emitted_symbols pointing to our struct.
2. Next we compute the diff for M. This is a merge, so we use the
combined diff code. In find_paths_generic(), we compute the
pairwise diff between each commit and its parent. Normally this is
done with DIFF_FORMAT_NO_OUTPUT, since we're just looking for
intersecting paths. But since "--stat --cc" shows the first-parent
stat, and since we're computing that diff anyway, we enable
DIFF_FORMAT_DIFFSTAT for the first parent. This outputs the stat
information immediately, saving us from running a separate
first-parent diff later.
But where does that output go? Normally it goes directly to stdout,
but because o->emitted_symbols is set, we queue it. As a result, we
don't actually print the diffstat for the merge commit (yet), which
is wrong.
3. Next we compute the diff for C. We're actually showing a patch
again, so we end up in diff_flush_patch_all_file_pairs(), but this
time we have the queued stat from step 2 waiting in our struct.
We add new elements to it for C's diff, and then flush the whole
thing. And we see the diffstat from M as part of C's diff, which is
wrong.
So triggering the bug really does require the combination of all of
those options.
To fix it, we can simply restore o->emitted_symbols to NULL after
flushing it, so that it does not affect anything outside of
diff_flush_patch_all_file_pairs(). This intuitively makes sense, since
nobody outside of that function is going to bother flushing it, so we
would not want them to write to it either.
In fact, we could take this a step further and turn the local "esm"
struct into a non-static variable that goes away after the function
ends. However, since it contains a dynamically sized array, we benefit
from amortizing the cost of allocations over many calls. So we'll leave
it as static to retain that benefit.
But let's push the zero-ing of esm.nr into the conditional for "if
(o->emitted_symbols)" to make it clear that we do not expect esm to hold
any values if we did not just try to use it. With the code as it is
written now, if we did encounter such a case (which I think would be a
bug), we'd silently leak those values without even bothering to display
them. With this change, we'd at least eventually show them, and somebody
would notice.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-24 20:32:41 +08:00
|
|
|
esm.nr = 0;
|
|
|
|
|
|
|
|
o->emitted_symbols = NULL;
|
2017-06-30 08:07:06 +08:00
|
|
|
}
|
2017-06-30 08:06:48 +08:00
|
|
|
}
|
|
|
|
|
diff: add an API for deferred freeing
Add a diff_free() function to free anything we may have allocated in
the "diff_options" struct, and the ability to make calling it a noop
by setting "no_free" in "diff_options".
This is required because when e.g. "git diff" is run we'll allocate
things in that struct, use the diff machinery once, and then exit.
But if we run e.g. "git log -p" we're going to re-use what we
allocated across multiple diff_flush() calls, and only want to free
things at the end.
We've thus ended up with features like the recently added "diff -I"[1]
where we'll leak memory. As it turns out it could have simply used the
pattern established in 6ea57703f6 (log: prepare log/log-tree to reuse
the diffopt.close_file attribute, 2016-06-22).
Manually adding more such flags to things log_tree_commit() every time
we need to allocate something would be tedious. Let's instead move
that fclose() code it to a new diff_free(), in anticipation of freeing
more things in that function in follow-up commits.
Some functions such as log_tree_commit() need an idiom of optionally
retaining a previous "no_free", as they may either free the memory
themselves, or their caller may do so. I'm keeping that idiom in
log_show_early() for good measure, even though I don't think it's
currently called in this manner. It also gets passed an existing
"struct rev_info", so future callers may want to set the "no_free"
flag.
This change is a bit hard to read because while the freeing pattern
we're introducing isn't unusual, the "file" member is a special
snowflake. We usually don't want to fclose() it. This is because
"file" is usually stdout, in which case we don't want to fclose()
it. We only want to opt-in to closing it when we e.g. open a file on
the filesystem. Thus the opt-in "close_file" flag.
So the API in general just needs a "no_free" flag to defer freeing,
but the "file" member still needs its "close_file" flag. This is made
more confusing because while refactoring this code we could replace
some "close_file=0" with "no_free=1", whereas others need to set both
flags.
This is because there were some cases where an existing "close_file=0"
meant "let's defer deallocation", and others where it meant "we don't
want to close this file handle at all".
1. 296d4a94e7 (diff: add -I<regex> that ignores matching changes,
2020-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 18:45:34 +08:00
|
|
|
static void diff_free_file(struct diff_options *options)
|
|
|
|
{
|
|
|
|
if (options->close_file)
|
|
|
|
fclose(options->file);
|
|
|
|
}
|
|
|
|
|
2021-02-11 18:45:35 +08:00
|
|
|
static void diff_free_ignore_regex(struct diff_options *options)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < options->ignore_regex_nr; i++) {
|
|
|
|
regfree(options->ignore_regex[i]);
|
|
|
|
free(options->ignore_regex[i]);
|
|
|
|
}
|
|
|
|
free(options->ignore_regex);
|
|
|
|
}
|
|
|
|
|
diff: add an API for deferred freeing
Add a diff_free() function to free anything we may have allocated in
the "diff_options" struct, and the ability to make calling it a noop
by setting "no_free" in "diff_options".
This is required because when e.g. "git diff" is run we'll allocate
things in that struct, use the diff machinery once, and then exit.
But if we run e.g. "git log -p" we're going to re-use what we
allocated across multiple diff_flush() calls, and only want to free
things at the end.
We've thus ended up with features like the recently added "diff -I"[1]
where we'll leak memory. As it turns out it could have simply used the
pattern established in 6ea57703f6 (log: prepare log/log-tree to reuse
the diffopt.close_file attribute, 2016-06-22).
Manually adding more such flags to things log_tree_commit() every time
we need to allocate something would be tedious. Let's instead move
that fclose() code it to a new diff_free(), in anticipation of freeing
more things in that function in follow-up commits.
Some functions such as log_tree_commit() need an idiom of optionally
retaining a previous "no_free", as they may either free the memory
themselves, or their caller may do so. I'm keeping that idiom in
log_show_early() for good measure, even though I don't think it's
currently called in this manner. It also gets passed an existing
"struct rev_info", so future callers may want to set the "no_free"
flag.
This change is a bit hard to read because while the freeing pattern
we're introducing isn't unusual, the "file" member is a special
snowflake. We usually don't want to fclose() it. This is because
"file" is usually stdout, in which case we don't want to fclose()
it. We only want to opt-in to closing it when we e.g. open a file on
the filesystem. Thus the opt-in "close_file" flag.
So the API in general just needs a "no_free" flag to defer freeing,
but the "file" member still needs its "close_file" flag. This is made
more confusing because while refactoring this code we could replace
some "close_file=0" with "no_free=1", whereas others need to set both
flags.
This is because there were some cases where an existing "close_file=0"
meant "let's defer deallocation", and others where it meant "we don't
want to close this file handle at all".
1. 296d4a94e7 (diff: add -I<regex> that ignores matching changes,
2020-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 18:45:34 +08:00
|
|
|
void diff_free(struct diff_options *options)
|
|
|
|
{
|
|
|
|
if (options->no_free)
|
|
|
|
return;
|
|
|
|
|
|
|
|
diff_free_file(options);
|
2021-02-11 18:45:35 +08:00
|
|
|
diff_free_ignore_regex(options);
|
2022-02-16 18:56:28 +08:00
|
|
|
clear_pathspec(&options->pathspec);
|
2022-02-16 18:56:29 +08:00
|
|
|
FREE_AND_NULL(options->parseopts);
|
diff: add an API for deferred freeing
Add a diff_free() function to free anything we may have allocated in
the "diff_options" struct, and the ability to make calling it a noop
by setting "no_free" in "diff_options".
This is required because when e.g. "git diff" is run we'll allocate
things in that struct, use the diff machinery once, and then exit.
But if we run e.g. "git log -p" we're going to re-use what we
allocated across multiple diff_flush() calls, and only want to free
things at the end.
We've thus ended up with features like the recently added "diff -I"[1]
where we'll leak memory. As it turns out it could have simply used the
pattern established in 6ea57703f6 (log: prepare log/log-tree to reuse
the diffopt.close_file attribute, 2016-06-22).
Manually adding more such flags to things log_tree_commit() every time
we need to allocate something would be tedious. Let's instead move
that fclose() code it to a new diff_free(), in anticipation of freeing
more things in that function in follow-up commits.
Some functions such as log_tree_commit() need an idiom of optionally
retaining a previous "no_free", as they may either free the memory
themselves, or their caller may do so. I'm keeping that idiom in
log_show_early() for good measure, even though I don't think it's
currently called in this manner. It also gets passed an existing
"struct rev_info", so future callers may want to set the "no_free"
flag.
This change is a bit hard to read because while the freeing pattern
we're introducing isn't unusual, the "file" member is a special
snowflake. We usually don't want to fclose() it. This is because
"file" is usually stdout, in which case we don't want to fclose()
it. We only want to opt-in to closing it when we e.g. open a file on
the filesystem. Thus the opt-in "close_file" flag.
So the API in general just needs a "no_free" flag to defer freeing,
but the "file" member still needs its "close_file" flag. This is made
more confusing because while refactoring this code we could replace
some "close_file=0" with "no_free=1", whereas others need to set both
flags.
This is because there were some cases where an existing "close_file=0"
meant "let's defer deallocation", and others where it meant "we don't
want to close this file handle at all".
1. 296d4a94e7 (diff: add -I<regex> that ignores matching changes,
2020-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 18:45:34 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void diff_flush(struct diff_options *options)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2006-06-25 01:21:53 +08:00
|
|
|
int i, output_format = options->output_format;
|
2006-06-27 20:09:17 +08:00
|
|
|
int separator = 0;
|
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 17:36:21 +08:00
|
|
|
int dirstat_by_line = 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
/*
|
|
|
|
* Order: raw, stat, summary, patch
|
|
|
|
* or: name/name-status/checkdiff (other bits clear)
|
|
|
|
*/
|
2022-02-02 10:37:34 +08:00
|
|
|
if (!q->nr && !options->additional_path_headers)
|
2006-06-27 20:09:17 +08:00
|
|
|
goto free_queue;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
if (output_format & (DIFF_FORMAT_RAW |
|
|
|
|
DIFF_FORMAT_NAME |
|
|
|
|
DIFF_FORMAT_NAME_STATUS |
|
|
|
|
DIFF_FORMAT_CHECKDIFF)) {
|
2006-04-22 14:57:45 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
2006-06-25 01:21:53 +08:00
|
|
|
if (check_pair_status(p))
|
|
|
|
flush_one_pair(p, options);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2006-06-27 20:09:17 +08:00
|
|
|
separator++;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2006-06-25 01:21:53 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (output_format & DIFF_FORMAT_DIRSTAT && options->flags.dirstat_by_line)
|
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 17:36:21 +08:00
|
|
|
dirstat_by_line = 1;
|
|
|
|
|
|
|
|
if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_SHORTSTAT|DIFF_FORMAT_NUMSTAT) ||
|
|
|
|
dirstat_by_line) {
|
2006-06-25 19:28:19 +08:00
|
|
|
struct diffstat_t diffstat;
|
2006-06-25 01:21:53 +08:00
|
|
|
|
2019-11-13 20:40:58 +08:00
|
|
|
compute_diffstat(options, &diffstat, q);
|
2006-10-12 18:01:00 +08:00
|
|
|
if (output_format & DIFF_FORMAT_NUMSTAT)
|
|
|
|
show_numstat(&diffstat, options);
|
|
|
|
if (output_format & DIFF_FORMAT_DIFFSTAT)
|
|
|
|
show_stats(&diffstat, options);
|
2007-12-12 15:46:30 +08:00
|
|
|
if (output_format & DIFF_FORMAT_SHORTSTAT)
|
2008-03-10 10:43:39 +08:00
|
|
|
show_shortstats(&diffstat, options);
|
2015-03-02 23:05:39 +08:00
|
|
|
if (output_format & DIFF_FORMAT_DIRSTAT && dirstat_by_line)
|
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 17:36:21 +08:00
|
|
|
show_dirstat_by_line(&diffstat, options);
|
2007-12-12 15:46:30 +08:00
|
|
|
free_diffstat_info(&diffstat);
|
2006-06-28 06:08:19 +08:00
|
|
|
separator++;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
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 17:36:21 +08:00
|
|
|
if ((output_format & DIFF_FORMAT_DIRSTAT) && !dirstat_by_line)
|
2008-02-13 09:06:58 +08:00
|
|
|
show_dirstat(options);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-06-27 20:09:17 +08:00
|
|
|
if (output_format & DIFF_FORMAT_SUMMARY && !is_summary_empty(q)) {
|
2010-05-26 15:23:54 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
diff_summary(options, q->queue[i]);
|
|
|
|
}
|
2006-06-28 06:08:19 +08:00
|
|
|
separator++;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2010-02-16 14:55:21 +08:00
|
|
|
if (output_format & DIFF_FORMAT_NO_OUTPUT &&
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.exit_with_status &&
|
|
|
|
options->flags.diff_from_contents) {
|
2010-02-16 14:55:21 +08:00
|
|
|
/*
|
|
|
|
* run diff_flush_patch for the exit status. setting
|
2013-07-23 05:02:23 +08:00
|
|
|
* options->file to /dev/null should be safe, because we
|
2010-02-16 14:55:21 +08:00
|
|
|
* aren't supposed to produce any output anyway.
|
|
|
|
*/
|
diff: add an API for deferred freeing
Add a diff_free() function to free anything we may have allocated in
the "diff_options" struct, and the ability to make calling it a noop
by setting "no_free" in "diff_options".
This is required because when e.g. "git diff" is run we'll allocate
things in that struct, use the diff machinery once, and then exit.
But if we run e.g. "git log -p" we're going to re-use what we
allocated across multiple diff_flush() calls, and only want to free
things at the end.
We've thus ended up with features like the recently added "diff -I"[1]
where we'll leak memory. As it turns out it could have simply used the
pattern established in 6ea57703f6 (log: prepare log/log-tree to reuse
the diffopt.close_file attribute, 2016-06-22).
Manually adding more such flags to things log_tree_commit() every time
we need to allocate something would be tedious. Let's instead move
that fclose() code it to a new diff_free(), in anticipation of freeing
more things in that function in follow-up commits.
Some functions such as log_tree_commit() need an idiom of optionally
retaining a previous "no_free", as they may either free the memory
themselves, or their caller may do so. I'm keeping that idiom in
log_show_early() for good measure, even though I don't think it's
currently called in this manner. It also gets passed an existing
"struct rev_info", so future callers may want to set the "no_free"
flag.
This change is a bit hard to read because while the freeing pattern
we're introducing isn't unusual, the "file" member is a special
snowflake. We usually don't want to fclose() it. This is because
"file" is usually stdout, in which case we don't want to fclose()
it. We only want to opt-in to closing it when we e.g. open a file on
the filesystem. Thus the opt-in "close_file" flag.
So the API in general just needs a "no_free" flag to defer freeing,
but the "file" member still needs its "close_file" flag. This is made
more confusing because while refactoring this code we could replace
some "close_file=0" with "no_free=1", whereas others need to set both
flags.
This is because there were some cases where an existing "close_file=0"
meant "let's defer deallocation", and others where it meant "we don't
want to close this file handle at all".
1. 296d4a94e7 (diff: add -I<regex> that ignores matching changes,
2020-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 18:45:34 +08:00
|
|
|
diff_free_file(options);
|
2017-05-03 18:16:46 +08:00
|
|
|
options->file = xfopen("/dev/null", "w");
|
2010-02-16 14:55:21 +08:00
|
|
|
options->close_file = 1;
|
diff.c: color moved lines differently
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different colors):
[OM] -void sensitive_stuff(void)
[OM] -{
[OM] - if (!is_authorized_user())
[OM] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OM] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NM] + sensitive_stuff(spanning,
[NM] + multiple,
[NM] + lines);
[NM] +}
However adjacent blocks may be problematic. For example, in this
potentially malicious patch, the swapping of blocks can be spotted:
[OM] -void sensitive_stuff(void)
[OM] -{
[OMA] - if (!is_authorized_user())
[OMA] - die("unauthorized");
[OM] - sensitive_stuff(spanning,
[OM] - multiple,
[OM] - lines);
[OMA] -}
void another_function()
{
[del] - printf("foo");
[add] + printf("bar");
}
[NM] +void sensitive_stuff(void)
[NM] +{
[NMA] + sensitive_stuff(spanning,
[NMA] + multiple,
[NMA] + lines);
[NM] + if (!is_authorized_user())
[NM] + die("unauthorized");
[NMA] +}
If the moved code is larger, it is easier to hide some permutation in the
code, which is why some alternative coloring is needed.
This patch implements the first mode:
* basic alternating 'Zebra' mode
This conveys all information needed to the user. Defer customization to
later patches.
First I implemented an alternative design, which would try to fingerprint
a line by its neighbors to detect if we are in a block or at the boundary.
This idea iss error prone as it inspected each line and its neighboring
lines to determine if the line was (a) moved and (b) if was deep inside
a hunk by having matching neighboring lines. This is unreliable as the
we can construct hunks which have equal neighbors that just exceed the
number of lines inspected. (Think of 'AXYZBXYZCXYZD..' with each letter
as a line, that is permutated to AXYZCXYZBXYZD..').
Instead this provides a dynamic programming greedy algorithm that finds
the largest moved hunk and then has several modes on highlighting bounds.
A note on the options '--submodule=diff' and '--color-words/--word-diff':
In the conversion to use emit_line in the prior patches both submodules
as well as word diff output carefully chose to call emit_line with sign=0.
All output with sign=0 is ignored for move detection purposes in this
patch, such that no weird looking output will be generated for these
cases. This leads to another thought: We could pass on '--color-moved' to
submodules such that they color up moved lines for themselves. If we'd do
so only line moves within a repository boundary are marked up.
It is useful to have moved lines colored, but there are annoying corner
cases, such as a single line moved, that is very common. For example
in a typical patch of C code, we have closing braces that end statement
blocks or functions.
While it is technically true that these lines are moved as they show up
elsewhere, it is harmful for the review as the reviewers attention is
drawn to such a minor side annoyance.
For now let's have a simple solution of hardcoding the number of
moved lines to be at least 3 before coloring them. Note, that the
length is applied across all blocks to find the 'lonely' blocks
that pollute new code, but do not interfere with a permutated
block where each permutation has less lines than 3.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-01 04:53:07 +08:00
|
|
|
options->color_moved = 0;
|
2010-02-16 14:55:21 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
if (check_pair_status(p))
|
|
|
|
diff_flush_patch(p, options);
|
|
|
|
if (options->found_changes)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
if (output_format & DIFF_FORMAT_PATCH) {
|
2006-06-27 20:09:17 +08:00
|
|
|
if (separator) {
|
2017-06-30 08:06:53 +08:00
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_SEPARATOR, NULL, 0, 0);
|
2017-06-30 08:07:04 +08:00
|
|
|
if (options->stat_sep)
|
2006-06-27 20:09:17 +08:00
|
|
|
/* attach patch instead of inline */
|
2017-06-30 08:07:04 +08:00
|
|
|
emit_diff_symbol(options, DIFF_SYMBOL_STAT_SEP,
|
|
|
|
NULL, 0, 0);
|
2006-06-25 01:21:53 +08:00
|
|
|
}
|
|
|
|
|
2017-06-30 08:06:48 +08:00
|
|
|
diff_flush_patch_all_file_pairs(options);
|
2006-05-14 20:13:49 +08:00
|
|
|
}
|
|
|
|
|
2006-09-07 14:35:42 +08:00
|
|
|
if (output_format & DIFF_FORMAT_CALLBACK)
|
|
|
|
options->format_callback(q, options, options->format_callback_data);
|
|
|
|
|
2006-06-25 01:21:53 +08:00
|
|
|
for (i = 0; i < q->nr; i++)
|
|
|
|
diff_free_filepair(q->queue[i]);
|
2006-06-27 20:09:17 +08:00
|
|
|
free_queue:
|
2006-04-22 14:57:45 +08:00
|
|
|
free(q->queue);
|
2010-05-07 12:52:27 +08:00
|
|
|
DIFF_QUEUE_CLEAR(q);
|
diff: add an API for deferred freeing
Add a diff_free() function to free anything we may have allocated in
the "diff_options" struct, and the ability to make calling it a noop
by setting "no_free" in "diff_options".
This is required because when e.g. "git diff" is run we'll allocate
things in that struct, use the diff machinery once, and then exit.
But if we run e.g. "git log -p" we're going to re-use what we
allocated across multiple diff_flush() calls, and only want to free
things at the end.
We've thus ended up with features like the recently added "diff -I"[1]
where we'll leak memory. As it turns out it could have simply used the
pattern established in 6ea57703f6 (log: prepare log/log-tree to reuse
the diffopt.close_file attribute, 2016-06-22).
Manually adding more such flags to things log_tree_commit() every time
we need to allocate something would be tedious. Let's instead move
that fclose() code it to a new diff_free(), in anticipation of freeing
more things in that function in follow-up commits.
Some functions such as log_tree_commit() need an idiom of optionally
retaining a previous "no_free", as they may either free the memory
themselves, or their caller may do so. I'm keeping that idiom in
log_show_early() for good measure, even though I don't think it's
currently called in this manner. It also gets passed an existing
"struct rev_info", so future callers may want to set the "no_free"
flag.
This change is a bit hard to read because while the freeing pattern
we're introducing isn't unusual, the "file" member is a special
snowflake. We usually don't want to fclose() it. This is because
"file" is usually stdout, in which case we don't want to fclose()
it. We only want to opt-in to closing it when we e.g. open a file on
the filesystem. Thus the opt-in "close_file" flag.
So the API in general just needs a "no_free" flag to defer freeing,
but the "file" member still needs its "close_file" flag. This is made
more confusing because while refactoring this code we could replace
some "close_file=0" with "no_free=1", whereas others need to set both
flags.
This is because there were some cases where an existing "close_file=0"
meant "let's defer deallocation", and others where it meant "we don't
want to close this file handle at all".
1. 296d4a94e7 (diff: add -I<regex> that ignores matching changes,
2020-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 18:45:34 +08:00
|
|
|
diff_free(options);
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
|
|
|
|
/*
|
2009-08-31 04:27:02 +08:00
|
|
|
* Report the content-level differences with HAS_CHANGES;
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
* diff_addremove/diff_change does not set the bit when
|
|
|
|
* DIFF_FROM_CONTENTS is in effect (e.g. with -w).
|
|
|
|
*/
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.diff_from_contents) {
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
if (options->found_changes)
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.has_changes = 1;
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
else
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.has_changes = 0;
|
diff: change semantics of "ignore whitespace" options
Traditionally, the --ignore-whitespace* options have merely meant to tell
the diff output routine that some class of differences are not worth
showing in the textual diff output, so that the end user has easier time
to review the remaining (presumably more meaningful) changes. These
options never affected the outcome of the command, given as the exit
status when the --exit-code option was in effect (either directly or
indirectly).
When you have only whitespace changes, however, you might expect
git diff -b --exit-code
to report that there is _no_ change with zero exit status.
Change the semantics of --ignore-whitespace* options to mean more than
"omit showing the difference in text".
The exit status, when --exit-code is in effect, is computed by checking if
we found any differences at the path level, while diff frontends feed
filepairs to the diffcore engine. When "ignore whitespace" options are in
effect, we defer this determination until the very end of diffcore
transformation. We simply do not know until the textual diff is
generated, which comes very late in the pipeline.
When --quiet is in effect, various diff frontends optimize by breaking out
early from the loop that enumerates the filepairs, when we find the first
path level difference; when --ignore-whitespace* is used the above change
automatically disables this optimization.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23 03:45:29 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2013-07-18 06:09:34 +08:00
|
|
|
static int match_filter(const struct diff_options *options, const struct diff_filepair *p)
|
|
|
|
{
|
|
|
|
return (((p->status == DIFF_STATUS_MODIFIED) &&
|
|
|
|
((p->score &&
|
2013-07-18 06:05:46 +08:00
|
|
|
filter_bit_tst(DIFF_STATUS_FILTER_BROKEN, options)) ||
|
2013-07-18 06:09:34 +08:00
|
|
|
(!p->score &&
|
2013-07-18 06:05:46 +08:00
|
|
|
filter_bit_tst(DIFF_STATUS_MODIFIED, options)))) ||
|
2013-07-18 06:09:34 +08:00
|
|
|
((p->status != DIFF_STATUS_MODIFIED) &&
|
2013-07-18 06:05:46 +08:00
|
|
|
filter_bit_tst(p->status, options)));
|
2013-07-18 06:09:34 +08:00
|
|
|
}
|
|
|
|
|
2013-07-18 05:19:24 +08:00
|
|
|
static void diffcore_apply_filter(struct diff_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
struct diff_queue_struct outq;
|
2013-07-18 05:19:24 +08:00
|
|
|
|
2010-05-07 12:52:27 +08:00
|
|
|
DIFF_QUEUE_CLEAR(&outq);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2013-07-18 06:05:46 +08:00
|
|
|
if (!options->filter)
|
2006-04-22 14:57:45 +08:00
|
|
|
return;
|
|
|
|
|
2013-07-18 06:05:46 +08:00
|
|
|
if (filter_bit_tst(DIFF_STATUS_FILTER_AON, options)) {
|
2006-04-22 14:57:45 +08:00
|
|
|
int found;
|
|
|
|
for (i = found = 0; !found && i < q->nr; i++) {
|
2013-07-18 06:09:34 +08:00
|
|
|
if (match_filter(options, q->queue[i]))
|
2006-04-22 14:57:45 +08:00
|
|
|
found++;
|
|
|
|
}
|
|
|
|
if (found)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* otherwise we will clear the whole queue
|
|
|
|
* by copying the empty outq at the end of this
|
|
|
|
* function, but first clear the current entries
|
|
|
|
* in the queue.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < q->nr; i++)
|
|
|
|
diff_free_filepair(q->queue[i]);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* Only the matching ones */
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
2013-07-18 06:09:34 +08:00
|
|
|
if (match_filter(options, p))
|
2006-04-22 14:57:45 +08:00
|
|
|
diff_q(&outq, p);
|
|
|
|
else
|
|
|
|
diff_free_filepair(p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(q->queue);
|
|
|
|
*q = outq;
|
|
|
|
}
|
|
|
|
|
2007-09-08 18:30:22 +08:00
|
|
|
/* Check whether two filespecs with the same mode and size are identical */
|
2018-09-21 23:57:19 +08:00
|
|
|
static int diff_filespec_is_identical(struct repository *r,
|
|
|
|
struct diff_filespec *one,
|
2007-09-08 18:30:22 +08:00
|
|
|
struct diff_filespec *two)
|
|
|
|
{
|
2008-03-02 16:07:59 +08:00
|
|
|
if (S_ISGITLINK(one->mode))
|
|
|
|
return 0;
|
2020-04-08 06:11:41 +08:00
|
|
|
if (diff_populate_filespec(r, one, NULL))
|
2007-09-08 18:30:22 +08:00
|
|
|
return 0;
|
2020-04-08 06:11:41 +08:00
|
|
|
if (diff_populate_filespec(r, two, NULL))
|
2007-09-08 18:30:22 +08:00
|
|
|
return 0;
|
|
|
|
return !memcmp(one->data, two->data, one->size);
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static int diff_filespec_check_stat_unmatch(struct repository *r,
|
|
|
|
struct diff_filepair *p)
|
2014-01-25 14:46:49 +08:00
|
|
|
{
|
2020-04-08 06:11:41 +08:00
|
|
|
struct diff_populate_filespec_options dpf_options = {
|
|
|
|
.check_size_only = 1,
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
.missing_object_cb = diff_queued_diff_prefetch,
|
|
|
|
.missing_object_data = r,
|
2020-04-08 06:11:41 +08:00
|
|
|
};
|
|
|
|
|
2014-01-25 14:46:50 +08:00
|
|
|
if (p->done_skip_stat_unmatch)
|
|
|
|
return p->skip_stat_unmatch_result;
|
|
|
|
|
|
|
|
p->done_skip_stat_unmatch = 1;
|
|
|
|
p->skip_stat_unmatch_result = 0;
|
2014-01-25 14:46:49 +08:00
|
|
|
/*
|
|
|
|
* 1. Entries that come from stat info dirtiness
|
|
|
|
* always have both sides (iow, not create/delete),
|
|
|
|
* one side of the object name is unknown, with
|
|
|
|
* the same mode and size. Keep the ones that
|
|
|
|
* do not match these criteria. They have real
|
|
|
|
* differences.
|
|
|
|
*
|
|
|
|
* 2. At this point, the file is known to be modified,
|
|
|
|
* with the same mode and size, and the object
|
|
|
|
* name of one side is unknown. Need to inspect
|
|
|
|
* the identical contents.
|
|
|
|
*/
|
|
|
|
if (!DIFF_FILE_VALID(p->one) || /* (1) */
|
|
|
|
!DIFF_FILE_VALID(p->two) ||
|
2016-06-25 07:09:24 +08:00
|
|
|
(p->one->oid_valid && p->two->oid_valid) ||
|
2014-01-25 14:46:49 +08:00
|
|
|
(p->one->mode != p->two->mode) ||
|
2020-04-08 06:11:41 +08:00
|
|
|
diff_populate_filespec(r, p->one, &dpf_options) ||
|
|
|
|
diff_populate_filespec(r, p->two, &dpf_options) ||
|
2014-01-25 14:46:49 +08:00
|
|
|
(p->one->size != p->two->size) ||
|
2018-09-21 23:57:19 +08:00
|
|
|
!diff_filespec_is_identical(r, p->one, p->two)) /* (2) */
|
2014-01-25 14:46:50 +08:00
|
|
|
p->skip_stat_unmatch_result = 1;
|
|
|
|
return p->skip_stat_unmatch_result;
|
2014-01-25 14:46:49 +08:00
|
|
|
}
|
|
|
|
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-04 04:33:31 +08:00
|
|
|
static void diffcore_skip_stat_unmatch(struct diff_options *diffopt)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
struct diff_queue_struct outq;
|
2010-05-07 12:52:27 +08:00
|
|
|
DIFF_QUEUE_CLEAR(&outq);
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-04 04:33:31 +08:00
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
if (diff_filespec_check_stat_unmatch(diffopt->repo, p))
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-04 04:33:31 +08:00
|
|
|
diff_q(&outq, p);
|
|
|
|
else {
|
|
|
|
/*
|
|
|
|
* The caller can subtract 1 from skip_stat_unmatch
|
|
|
|
* to determine how many paths were dirty only
|
|
|
|
* due to stat info mismatch.
|
|
|
|
*/
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!diffopt->flags.no_index)
|
2007-08-15 06:41:00 +08:00
|
|
|
diffopt->skip_stat_unmatch++;
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-04 04:33:31 +08:00
|
|
|
diff_free_filepair(p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(q->queue);
|
|
|
|
*q = outq;
|
|
|
|
}
|
|
|
|
|
unpack-trees.c: look ahead in the index
This makes the traversal of index be in sync with the tree traversal.
When unpack_callback() is fed a set of tree entries from trees, it
inspects the name of the entry and checks if the an index entry with
the same name could be hiding behind the current index entry, and
(1) if the name appears in the index as a leaf node, it is also
fed to the n_way_merge() callback function;
(2) if the name is a directory in the index, i.e. there are entries in
that are underneath it, then nothing is fed to the n_way_merge()
callback function;
(3) otherwise, if the name comes before the first eligible entry in the
index, the index entry is first unpacked alone.
When traverse_trees_recursive() descends into a subdirectory, the
cache_bottom pointer is moved to walk index entries within that directory.
All of these are omitted for diff-index, which does not even want to be
fed an index entry and a tree entry with D/F conflicts.
This fixes 3-way read-tree and exposes a bug in other parts of the system
in t6035, test #5. The test prepares these three trees:
O = HEAD^
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
A = HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob 587be6b4c3f93f93c489c0111bba5596147a26cb a/x
B = master
120000 blob a36b77384451ea1de7bd340ffca868249626bc52 a/b
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
With a clean index that matches HEAD, running
git read-tree -m -u --aggressive $O $A $B
now yields
120000 a36b77384451ea1de7bd340ffca868249626bc52 3 a/b
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 a/b-2/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 a/b/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 a/b/c/d
100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0 a/x
which is correct. "master" created "a/b" symlink that did not exist,
and removed "a/b/c/d" while HEAD did not do touch either path.
Before this series, read-tree did not notice the situation and resolved
addition of "a/b" and removal of "a/b/c/d" independently. If A = HEAD had
another path "a/b/c/e" added, this merge should conflict but instead it
silently resolved "a/b" and then immediately overwrote it to add
"a/b/c/e", which was quite bogus.
Tests in t1012 start to work with this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-20 15:03:39 +08:00
|
|
|
static int diffnamecmp(const void *a_, const void *b_)
|
|
|
|
{
|
|
|
|
const struct diff_filepair *a = *((const struct diff_filepair **)a_);
|
|
|
|
const struct diff_filepair *b = *((const struct diff_filepair **)b_);
|
|
|
|
const char *name_a, *name_b;
|
|
|
|
|
|
|
|
name_a = a->one ? a->one->path : a->two->path;
|
|
|
|
name_b = b->one ? b->one->path : b->two->path;
|
|
|
|
return strcmp(name_a, name_b);
|
|
|
|
}
|
|
|
|
|
2019-02-14 13:48:03 +08:00
|
|
|
void diffcore_fix_diff_index(void)
|
unpack-trees.c: look ahead in the index
This makes the traversal of index be in sync with the tree traversal.
When unpack_callback() is fed a set of tree entries from trees, it
inspects the name of the entry and checks if the an index entry with
the same name could be hiding behind the current index entry, and
(1) if the name appears in the index as a leaf node, it is also
fed to the n_way_merge() callback function;
(2) if the name is a directory in the index, i.e. there are entries in
that are underneath it, then nothing is fed to the n_way_merge()
callback function;
(3) otherwise, if the name comes before the first eligible entry in the
index, the index entry is first unpacked alone.
When traverse_trees_recursive() descends into a subdirectory, the
cache_bottom pointer is moved to walk index entries within that directory.
All of these are omitted for diff-index, which does not even want to be
fed an index entry and a tree entry with D/F conflicts.
This fixes 3-way read-tree and exposes a bug in other parts of the system
in t6035, test #5. The test prepares these three trees:
O = HEAD^
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
A = HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob 587be6b4c3f93f93c489c0111bba5596147a26cb a/x
B = master
120000 blob a36b77384451ea1de7bd340ffca868249626bc52 a/b
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
With a clean index that matches HEAD, running
git read-tree -m -u --aggressive $O $A $B
now yields
120000 a36b77384451ea1de7bd340ffca868249626bc52 3 a/b
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 a/b-2/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 a/b/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 a/b/c/d
100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0 a/x
which is correct. "master" created "a/b" symlink that did not exist,
and removed "a/b/c/d" while HEAD did not do touch either path.
Before this series, read-tree did not notice the situation and resolved
addition of "a/b" and removal of "a/b/c/d" independently. If A = HEAD had
another path "a/b/c/e" added, this merge should conflict but instead it
silently resolved "a/b" and then immediately overwrote it to add
"a/b/c/e", which was quite bogus.
Tests in t1012 start to work with this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-20 15:03:39 +08:00
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2016-09-29 23:27:31 +08:00
|
|
|
QSORT(q->queue, q->nr, diffnamecmp);
|
unpack-trees.c: look ahead in the index
This makes the traversal of index be in sync with the tree traversal.
When unpack_callback() is fed a set of tree entries from trees, it
inspects the name of the entry and checks if the an index entry with
the same name could be hiding behind the current index entry, and
(1) if the name appears in the index as a leaf node, it is also
fed to the n_way_merge() callback function;
(2) if the name is a directory in the index, i.e. there are entries in
that are underneath it, then nothing is fed to the n_way_merge()
callback function;
(3) otherwise, if the name comes before the first eligible entry in the
index, the index entry is first unpacked alone.
When traverse_trees_recursive() descends into a subdirectory, the
cache_bottom pointer is moved to walk index entries within that directory.
All of these are omitted for diff-index, which does not even want to be
fed an index entry and a tree entry with D/F conflicts.
This fixes 3-way read-tree and exposes a bug in other parts of the system
in t6035, test #5. The test prepares these three trees:
O = HEAD^
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
A = HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b/c/d
100644 blob 587be6b4c3f93f93c489c0111bba5596147a26cb a/x
B = master
120000 blob a36b77384451ea1de7bd340ffca868249626bc52 a/b
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/b-2/c/d
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a/x
With a clean index that matches HEAD, running
git read-tree -m -u --aggressive $O $A $B
now yields
120000 a36b77384451ea1de7bd340ffca868249626bc52 3 a/b
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 a/b-2/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 a/b/c/d
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 a/b/c/d
100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0 a/x
which is correct. "master" created "a/b" symlink that did not exist,
and removed "a/b/c/d" while HEAD did not do touch either path.
Before this series, read-tree did not notice the situation and resolved
addition of "a/b" and removal of "a/b/c/d" independently. If A = HEAD had
another path "a/b/c/e" added, this merge should conflict but instead it
silently resolved "a/b" and then immediately overwrote it to add
"a/b/c/e", which was quite bogus.
Tests in t1012 start to work with this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-20 15:03:39 +08:00
|
|
|
}
|
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
void diff_add_if_missing(struct repository *r,
|
|
|
|
struct oid_array *to_fetch,
|
|
|
|
const struct diff_filespec *filespec)
|
2019-04-06 01:09:34 +08:00
|
|
|
{
|
|
|
|
if (filespec && filespec->oid_valid &&
|
2019-08-21 04:53:20 +08:00
|
|
|
!S_ISGITLINK(filespec->mode) &&
|
2019-04-06 01:09:34 +08:00
|
|
|
oid_object_info_extended(r, &filespec->oid, NULL,
|
|
|
|
OBJECT_INFO_FOR_PREFETCH))
|
|
|
|
oid_array_append(to_fetch, &filespec->oid);
|
|
|
|
}
|
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
void diff_queued_diff_prefetch(void *repository)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
struct repository *repo = repository;
|
|
|
|
int i;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
struct oid_array to_fetch = OID_ARRAY_INIT;
|
2019-04-06 01:09:34 +08:00
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
diff_add_if_missing(repo, &to_fetch, p->one);
|
|
|
|
diff_add_if_missing(repo, &to_fetch, p->two);
|
2019-04-06 01:09:34 +08:00
|
|
|
}
|
|
|
|
|
diff: restrict when prefetching occurs
Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08)
optimized "diff" by prefetching blobs in a partial clone, but there are
some cases wherein blobs do not need to be prefetched. In these cases,
any command that uses the diff machinery will unnecessarily fetch blobs.
diffcore_std() may read blobs when it calls the following functions:
(1) diffcore_skip_stat_unmatch() (controlled by the config variable
diff.autorefreshindex)
(2) diffcore_break() and diffcore_merge_broken() (for break-rewrite
detection)
(3) diffcore_rename() (for rename detection)
(4) diffcore_pickaxe() (for detecting addition/deletion of specified
string)
Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(),
diffcore_break(), and diffcore_rename() to prefetch blobs upon the first
read of a missing object. This covers (1), (2), and (3): to cover the
rest, teach diffcore_std() to prefetch if the output type is one that
includes blob data (and hence blob data will be required later anyway),
or if it knows that (4) will be run.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-08 06:11:43 +08:00
|
|
|
/*
|
|
|
|
* NEEDSWORK: Consider deduplicating the OIDs sent.
|
|
|
|
*/
|
|
|
|
promisor_remote_get_direct(repo, to_fetch.oid, to_fetch.nr);
|
|
|
|
|
|
|
|
oid_array_clear(&to_fetch);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diffcore_std(struct diff_options *options)
|
|
|
|
{
|
|
|
|
int output_formats_to_prefetch = DIFF_FORMAT_DIFFSTAT |
|
|
|
|
DIFF_FORMAT_NUMSTAT |
|
|
|
|
DIFF_FORMAT_PATCH |
|
|
|
|
DIFF_FORMAT_SHORTSTAT |
|
|
|
|
DIFF_FORMAT_DIRSTAT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if the user requested a blob-data-requiring diff output and/or
|
|
|
|
* break-rewrite detection (which requires blob data). If yes, prefetch
|
|
|
|
* the diff pairs.
|
|
|
|
*
|
|
|
|
* If no prefetching occurs, diffcore_rename() will prefetch if it
|
|
|
|
* decides that it needs inexact rename detection.
|
|
|
|
*/
|
|
|
|
if (options->repo == the_repository && has_promisor_remote() &&
|
|
|
|
(options->output_format & output_formats_to_prefetch ||
|
|
|
|
options->pickaxe_opts & DIFF_PICKAXE_KINDS_MASK))
|
|
|
|
diff_queued_diff_prefetch(options->repo);
|
|
|
|
|
combine-diff: speed it up, by using multiparent diff tree-walker directly
As was recently shown in "combine-diff: optimize
combine_diff_path sets intersection", combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25% of the slowness, and as my tracing showed, for linux.git
v3.10..v3.11, for merges a lot of time is spent computing
diff(commit,commit^2) just to only then intersect that huge diff to
almost small set of files from diff(commit,commit^1).
In previous commit, we described the problem in more details, and
reworked the diff tree-walker to be general one - i.e. to work in
multiple parent case too. Now is the time to take advantage of it for
finding paths for combine diff.
The implementation is straightforward - if we know, we can get generated
diff paths directly, and at present that means no diff filtering or
rename/copy detection was requested(*), we can call multiparent tree-walker
directly and get ready paths.
(*) because e.g. at present, all diffcore transformations work on
diff_filepair queues, but in the future, that limitation can be
lifted, if filters would operate directly on combine_diff_paths.
Timings for `git log --raw --no-abbrev --no-renames` without `-c` ("git log")
and with `-c` ("git log -c") and with `-c --merges` ("git log -c --merges")
before and after the patch are as follows:
linux.git v3.10..v3.11
log log -c log -c --merges
before 1.9s 16.4s 15.2s
after 1.9s 2.4s 1.1s
The result stayed the same.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-25 00:21:51 +08:00
|
|
|
/* NOTE please keep the following in sync with diff_tree_combined() */
|
2008-09-07 10:09:16 +08:00
|
|
|
if (options->skip_stat_unmatch)
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-04 04:33:31 +08:00
|
|
|
diffcore_skip_stat_unmatch(options);
|
2010-08-14 03:17:45 +08:00
|
|
|
if (!options->found_follow) {
|
|
|
|
/* See try_to_follow_renames() in tree-diff.c */
|
|
|
|
if (options->break_opt != -1)
|
2018-09-21 23:57:19 +08:00
|
|
|
diffcore_break(options->repo,
|
|
|
|
options->break_opt);
|
2010-08-14 03:17:45 +08:00
|
|
|
if (options->detect_rename)
|
|
|
|
diffcore_rename(options);
|
|
|
|
if (options->break_opt != -1)
|
|
|
|
diffcore_merge_broken();
|
|
|
|
}
|
2018-01-05 06:50:41 +08:00
|
|
|
if (options->pickaxe_opts & DIFF_PICKAXE_KINDS_MASK)
|
2010-09-01 04:44:39 +08:00
|
|
|
diffcore_pickaxe(options);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (options->orderfile)
|
|
|
|
diffcore_order(options->orderfile);
|
diff: --{rotate,skip}-to=<path>
In the implementation of "git difftool", there is a case where the
user wants to start viewing the diffs at a specific path and
continue on to the rest, optionally wrapping around to the
beginning. Since it is somewhat cumbersome to implement such a
feature as a post-processing step of "git diff" output, let's
support it internally with two new options.
- "git diff --rotate-to=C", when the resulting patch would show
paths A B C D E without the option, would "rotate" the paths to
shows patch to C D E A B instead. It is an error when there is
no patch for C is shown.
- "git diff --skip-to=C" would instead "skip" the paths before C,
and shows patch to C D E. Again, it is an error when there is no
patch for C is shown.
- "git log [-p]" also accepts these two options, but it is not an
error if there is no change to the specified path. Instead, the
set of output paths are rotated or skipped to the specified path
or the first path that sorts after the specified path.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-12 03:57:50 +08:00
|
|
|
if (options->rotate_to)
|
|
|
|
diffcore_rotate(options);
|
2010-08-14 03:17:45 +08:00
|
|
|
if (!options->found_follow)
|
|
|
|
/* See try_to_follow_renames() in tree-diff.c */
|
|
|
|
diff_resolve_rename_copy();
|
2013-07-18 05:19:24 +08:00
|
|
|
diffcore_apply_filter(options);
|
2007-03-15 02:12:13 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (diff_queued_diff.nr && !options->flags.diff_from_contents)
|
|
|
|
options->flags.has_changes = 1;
|
2007-11-11 03:05:14 +08:00
|
|
|
else
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.has_changes = 0;
|
2010-05-07 12:52:28 +08:00
|
|
|
|
2010-08-14 03:17:45 +08:00
|
|
|
options->found_follow = 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2007-12-14 15:40:27 +08:00
|
|
|
int diff_result_code(struct diff_options *opt, int status)
|
|
|
|
{
|
|
|
|
int result = 0;
|
2011-01-07 05:50:06 +08:00
|
|
|
|
2013-03-22 03:53:38 +08:00
|
|
|
diff_warn_rename_limit("diff.renameLimit",
|
2011-01-07 05:50:06 +08:00
|
|
|
opt->needed_rename_limit,
|
|
|
|
opt->degraded_cc_to_c);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!opt->flags.exit_with_status &&
|
2007-12-14 15:40:27 +08:00
|
|
|
!(opt->output_format & DIFF_FORMAT_CHECKDIFF))
|
|
|
|
return status;
|
2017-11-01 02:19:11 +08:00
|
|
|
if (opt->flags.exit_with_status &&
|
|
|
|
opt->flags.has_changes)
|
2007-12-14 15:40:27 +08:00
|
|
|
result |= 01;
|
|
|
|
if ((opt->output_format & DIFF_FORMAT_CHECKDIFF) &&
|
2017-11-01 02:19:11 +08:00
|
|
|
opt->flags.check_failed)
|
2007-12-14 15:40:27 +08:00
|
|
|
result |= 02;
|
|
|
|
return result;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2011-06-01 00:14:17 +08:00
|
|
|
int diff_can_quit_early(struct diff_options *opt)
|
|
|
|
{
|
2017-11-01 02:19:11 +08:00
|
|
|
return (opt->flags.quick &&
|
2011-06-01 00:14:17 +08:00
|
|
|
!opt->filter &&
|
2017-11-01 02:19:11 +08:00
|
|
|
opt->flags.has_changes);
|
2011-06-01 00:14:17 +08:00
|
|
|
}
|
|
|
|
|
2010-08-06 06:39:25 +08:00
|
|
|
/*
|
|
|
|
* Shall changes to this submodule be ignored?
|
|
|
|
*
|
|
|
|
* Submodule changes can be configured to be ignored separately for each path,
|
|
|
|
* but that configuration can be overridden from the command line.
|
|
|
|
*/
|
|
|
|
static int is_submodule_ignored(const char *path, struct diff_options *options)
|
|
|
|
{
|
|
|
|
int ignored = 0;
|
2017-11-01 02:19:05 +08:00
|
|
|
struct diff_flags orig_flags = options->flags;
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!options->flags.override_submodule_config)
|
2010-08-06 06:39:25 +08:00
|
|
|
set_diffopt_flags_from_submodule_config(options, path);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.ignore_submodules)
|
2010-08-06 06:39:25 +08:00
|
|
|
ignored = 1;
|
|
|
|
options->flags = orig_flags;
|
|
|
|
return ignored;
|
|
|
|
}
|
|
|
|
|
2019-11-13 20:40:58 +08:00
|
|
|
void compute_diffstat(struct diff_options *options,
|
|
|
|
struct diffstat_t *diffstat,
|
|
|
|
struct diff_queue_struct *q)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
memset(diffstat, 0, sizeof(struct diffstat_t));
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
if (check_pair_status(p))
|
|
|
|
diff_flush_stat(p, options, diffstat);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void diff_addremove(struct diff_options *options,
|
|
|
|
int addremove, unsigned mode,
|
2017-05-31 01:30:47 +08:00
|
|
|
const struct object_id *oid,
|
|
|
|
int oid_valid,
|
2010-01-19 04:26:18 +08:00
|
|
|
const char *concatpath, unsigned dirty_submodule)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct diff_filespec *one, *two;
|
|
|
|
|
2010-08-06 06:39:25 +08:00
|
|
|
if (S_ISGITLINK(mode) && is_submodule_ignored(concatpath, options))
|
2008-05-15 01:03:31 +08:00
|
|
|
return;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/* This may look odd, but it is a preparation for
|
|
|
|
* feeding "there are unchanged files which should
|
|
|
|
* not produce diffs, but when you are doing copy
|
|
|
|
* detection you would need them, so here they are"
|
|
|
|
* entries to the diff-core. They will be prefixed
|
|
|
|
* with something like '=' or '*' (I haven't decided
|
|
|
|
* which but should not make any difference).
|
2007-06-07 15:04:01 +08:00
|
|
|
* Feeding the same new and old to diff_change()
|
2006-04-22 14:57:45 +08:00
|
|
|
* also has the same effect.
|
|
|
|
* Before the final output happens, they are pruned after
|
|
|
|
* merged into rename/copy pairs as appropriate.
|
|
|
|
*/
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.reverse_diff)
|
2006-04-22 14:57:45 +08:00
|
|
|
addremove = (addremove == '+' ? '-' :
|
|
|
|
addremove == '-' ? '+' : addremove);
|
|
|
|
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(concatpath, options->prefix, options->prefix_length))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
one = alloc_filespec(concatpath);
|
|
|
|
two = alloc_filespec(concatpath);
|
|
|
|
|
|
|
|
if (addremove != '+')
|
2017-05-31 01:30:50 +08:00
|
|
|
fill_filespec(one, oid, oid_valid, mode);
|
2010-01-19 04:26:18 +08:00
|
|
|
if (addremove != '-') {
|
2017-05-31 01:30:50 +08:00
|
|
|
fill_filespec(two, oid, oid_valid, mode);
|
2010-01-19 04:26:18 +08:00
|
|
|
two->dirty_submodule = dirty_submodule;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
diff_queue(&diff_queued_diff, one, two);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!options->flags.diff_from_contents)
|
|
|
|
options->flags.has_changes = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_change(struct diff_options *options,
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
2017-05-31 01:30:49 +08:00
|
|
|
const struct object_id *old_oid,
|
|
|
|
const struct object_id *new_oid,
|
|
|
|
int old_oid_valid, int new_oid_valid,
|
2010-01-19 04:26:18 +08:00
|
|
|
const char *concatpath,
|
|
|
|
unsigned old_dirty_submodule, unsigned new_dirty_submodule)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct diff_filespec *one, *two;
|
2014-01-25 14:46:50 +08:00
|
|
|
struct diff_filepair *p;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2010-08-06 06:39:25 +08:00
|
|
|
if (S_ISGITLINK(old_mode) && S_ISGITLINK(new_mode) &&
|
|
|
|
is_submodule_ignored(concatpath, options))
|
2008-05-15 01:03:31 +08:00
|
|
|
return;
|
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.reverse_diff) {
|
2017-01-29 05:40:58 +08:00
|
|
|
SWAP(old_mode, new_mode);
|
2017-05-31 01:30:49 +08:00
|
|
|
SWAP(old_oid, new_oid);
|
|
|
|
SWAP(old_oid_valid, new_oid_valid);
|
2017-01-29 05:40:58 +08:00
|
|
|
SWAP(old_dirty_submodule, new_dirty_submodule);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
|
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(concatpath, options->prefix, options->prefix_length))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
one = alloc_filespec(concatpath);
|
|
|
|
two = alloc_filespec(concatpath);
|
2017-05-31 01:30:50 +08:00
|
|
|
fill_filespec(one, old_oid, old_oid_valid, old_mode);
|
|
|
|
fill_filespec(two, new_oid, new_oid_valid, new_mode);
|
2010-01-19 04:26:18 +08:00
|
|
|
one->dirty_submodule = old_dirty_submodule;
|
|
|
|
two->dirty_submodule = new_dirty_submodule;
|
2014-01-25 14:46:50 +08:00
|
|
|
p = diff_queue(&diff_queued_diff, one, two);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.diff_from_contents)
|
2014-01-25 14:46:50 +08:00
|
|
|
return;
|
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
if (options->flags.quick && options->skip_stat_unmatch &&
|
diff: discard blob data from stat-unmatched pairs
When performing a tree-level diff against the working tree, we may find
that our index stat information is dirty, so we queue a filepair to be
examined later. If the actual content hasn't changed, we call this a
stat-unmatch; the stat information was out of date, but there's no
actual diff. Normally diffcore_std() would detect and remove these
identical filepairs via diffcore_skip_stat_unmatch(). However, when
"--quiet" is used, we want to stop the diff as soon as we see any
changes, so we check for stat-unmatches immediately in diff_change().
That check may require us to actually load the file contents into the
pair of diff_filespecs. If we find that the pair isn't a stat-unmatch,
then no big deal; we'd likely load the contents later anyway to generate
a patch, do rename detection, etc, so we want to hold on to it. But if
it is a stat-unmatch, then we have no more use for that data; the whole
point is that we're going discard the pair. However, we never free the
allocated diff_filespec data.
In most cases, keeping that data isn't a problem. We don't expect a lot
of stat-unmatch entries, and since we're using --quiet, we'd quit as
soon as we saw such a real change anyway. However, there are extreme
cases where it makes a big difference:
1. We'd generally mmap() the working tree half of the pair. And since
the OS may limit the total number of maps, we can run afoul of this
in large repositories. E.g.:
$ cd linux
$ git ls-files | wc -l
67959
$ sysctl vm.max_map_count
vm.max_map_count = 65530
$ git ls-files | xargs touch ;# everything is stat-dirty!
$ git diff --quiet
fatal: mmap failed: Cannot allocate memory
It should be unusual to have so many files stat-dirty, but it's
possible if you've just run a script like "sed -i" or similar.
After this patch, the above correctly exits with code 0.
2. Even if you don't hit mmap limits, the index half of the pair will
have been pulled from the object database into heap memory. Again
in a clone of linux.git, running:
$ git ls-files | head -n 10000 | xargs touch
$ git diff --quiet
peaks at 145MB heap before this patch, and 94MB after.
This patch solves the problem by freeing any diff_filespec data we
picked up during the "--quiet" stat-unmatch check in diff_changes.
Nobody is going to need that data later, so there's no point holding on
to it. There are a few things to note:
- we could skip queueing the pair entirely, which could in theory save
a little work. But there's not much to save, as we need a
diff_filepair to feed to diff_filespec_check_stat_unmatch() anyway.
And since we cache the result of the stat-unmatch checks, a later
call to diffcore_skip_stat_unmatch() call will quickly skip over
them. The diffcore code also counts up the number of stat-unmatched
pairs as it removes them. It's doubtful any callers would care about
that in combination with --quiet, but we'd have to reimplement the
logic here to be on the safe side. So it's not really worth the
trouble.
- I didn't write a test, because we always produce the correct output
unless we run up against system mmap limits, which are both
unportable and expensive to test against. Measuring peak heap
would be interesting, but our perf suite isn't yet capable of that.
- note that diff without "--quiet" does not suffer from the same
problem. In diffcore_skip_stat_unmatch(), we detect the stat-unmatch
entries and drop them immediately, so we're not carrying their data
around.
- you _can_ still trigger the mmap limit problem if you truly have
that many files with actual changes. But it's rather unlikely. The
stat-unmatch check avoids loading the file contents if the sizes
don't match, so you'd need a pretty trivial change in every single
file. Likewise, inexact rename detection might load the data for
many files all at once. But you'd need not just 64k changes, but
that many deletions and additions. The most likely candidate is
perhaps break-detection, which would load the data for all pairs and
keep it around for the content-level diff. But again, you'd need 64k
actually changed files in the first place.
So it's still possible to trigger this case, but it seems like "I
accidentally made all my files stat-dirty" is the most likely case
in the real world.
Reported-by: Jan Christoph Uhde <Jan@UhdeJc.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-02 04:22:18 +08:00
|
|
|
!diff_filespec_check_stat_unmatch(options->repo, p)) {
|
|
|
|
diff_free_filespec_data(p->one);
|
|
|
|
diff_free_filespec_data(p->two);
|
2014-01-25 14:46:50 +08:00
|
|
|
return;
|
diff: discard blob data from stat-unmatched pairs
When performing a tree-level diff against the working tree, we may find
that our index stat information is dirty, so we queue a filepair to be
examined later. If the actual content hasn't changed, we call this a
stat-unmatch; the stat information was out of date, but there's no
actual diff. Normally diffcore_std() would detect and remove these
identical filepairs via diffcore_skip_stat_unmatch(). However, when
"--quiet" is used, we want to stop the diff as soon as we see any
changes, so we check for stat-unmatches immediately in diff_change().
That check may require us to actually load the file contents into the
pair of diff_filespecs. If we find that the pair isn't a stat-unmatch,
then no big deal; we'd likely load the contents later anyway to generate
a patch, do rename detection, etc, so we want to hold on to it. But if
it is a stat-unmatch, then we have no more use for that data; the whole
point is that we're going discard the pair. However, we never free the
allocated diff_filespec data.
In most cases, keeping that data isn't a problem. We don't expect a lot
of stat-unmatch entries, and since we're using --quiet, we'd quit as
soon as we saw such a real change anyway. However, there are extreme
cases where it makes a big difference:
1. We'd generally mmap() the working tree half of the pair. And since
the OS may limit the total number of maps, we can run afoul of this
in large repositories. E.g.:
$ cd linux
$ git ls-files | wc -l
67959
$ sysctl vm.max_map_count
vm.max_map_count = 65530
$ git ls-files | xargs touch ;# everything is stat-dirty!
$ git diff --quiet
fatal: mmap failed: Cannot allocate memory
It should be unusual to have so many files stat-dirty, but it's
possible if you've just run a script like "sed -i" or similar.
After this patch, the above correctly exits with code 0.
2. Even if you don't hit mmap limits, the index half of the pair will
have been pulled from the object database into heap memory. Again
in a clone of linux.git, running:
$ git ls-files | head -n 10000 | xargs touch
$ git diff --quiet
peaks at 145MB heap before this patch, and 94MB after.
This patch solves the problem by freeing any diff_filespec data we
picked up during the "--quiet" stat-unmatch check in diff_changes.
Nobody is going to need that data later, so there's no point holding on
to it. There are a few things to note:
- we could skip queueing the pair entirely, which could in theory save
a little work. But there's not much to save, as we need a
diff_filepair to feed to diff_filespec_check_stat_unmatch() anyway.
And since we cache the result of the stat-unmatch checks, a later
call to diffcore_skip_stat_unmatch() call will quickly skip over
them. The diffcore code also counts up the number of stat-unmatched
pairs as it removes them. It's doubtful any callers would care about
that in combination with --quiet, but we'd have to reimplement the
logic here to be on the safe side. So it's not really worth the
trouble.
- I didn't write a test, because we always produce the correct output
unless we run up against system mmap limits, which are both
unportable and expensive to test against. Measuring peak heap
would be interesting, but our perf suite isn't yet capable of that.
- note that diff without "--quiet" does not suffer from the same
problem. In diffcore_skip_stat_unmatch(), we detect the stat-unmatch
entries and drop them immediately, so we're not carrying their data
around.
- you _can_ still trigger the mmap limit problem if you truly have
that many files with actual changes. But it's rather unlikely. The
stat-unmatch check avoids loading the file contents if the sizes
don't match, so you'd need a pretty trivial change in every single
file. Likewise, inexact rename detection might load the data for
many files all at once. But you'd need not just 64k changes, but
that many deletions and additions. The most likely candidate is
perhaps break-detection, which would load the data for all pairs and
keep it around for the content-level diff. But again, you'd need 64k
actually changed files in the first place.
So it's still possible to trigger this case, but it seems like "I
accidentally made all my files stat-dirty" is the most likely case
in the real world.
Reported-by: Jan Christoph Uhde <Jan@UhdeJc.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-02 04:22:18 +08:00
|
|
|
}
|
2014-01-25 14:46:50 +08:00
|
|
|
|
2017-11-01 02:19:11 +08:00
|
|
|
options->flags.has_changes = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2011-04-23 07:05:58 +08:00
|
|
|
struct diff_filepair *diff_unmerge(struct diff_options *options, const char *path)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2011-04-23 06:55:55 +08:00
|
|
|
struct diff_filepair *pair;
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diff_filespec *one, *two;
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
|
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(path, options->prefix, options->prefix_length))
|
2011-04-23 06:55:55 +08:00
|
|
|
return NULL;
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 06:26:02 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
one = alloc_filespec(path);
|
|
|
|
two = alloc_filespec(path);
|
2011-04-23 06:55:55 +08:00
|
|
|
pair = diff_queue(&diff_queued_diff, one, two);
|
|
|
|
pair->is_unmerged = 1;
|
|
|
|
return pair;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2008-10-06 05:43:45 +08:00
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
static char *run_textconv(struct repository *r,
|
|
|
|
const char *pgm,
|
|
|
|
struct diff_filespec *spec,
|
|
|
|
size_t *outsize)
|
2008-10-06 05:43:45 +08:00
|
|
|
{
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
struct diff_tempfile *temp;
|
2014-08-20 03:09:35 +08:00
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
2008-10-06 05:43:45 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2010-03-31 01:36:03 +08:00
|
|
|
int err = 0;
|
2008-10-06 05:43:45 +08:00
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
temp = prepare_temp_file(r, spec->path, spec);
|
2021-11-26 06:52:21 +08:00
|
|
|
strvec_push(&child.args, pgm);
|
|
|
|
strvec_push(&child.args, temp->name);
|
2008-10-06 05:43:45 +08:00
|
|
|
|
2009-12-30 19:01:09 +08:00
|
|
|
child.use_shell = 1;
|
2008-10-06 05:43:45 +08:00
|
|
|
child.out = -1;
|
2010-03-31 01:36:03 +08:00
|
|
|
if (start_command(&child)) {
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
remove_tempfile();
|
2008-10-06 05:43:45 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
2010-03-31 01:36:03 +08:00
|
|
|
|
|
|
|
if (strbuf_read(&buf, child.out, 0) < 0)
|
|
|
|
err = error("error reading from textconv command '%s'", pgm);
|
2009-12-30 17:02:53 +08:00
|
|
|
close(child.out);
|
2010-03-31 01:36:03 +08:00
|
|
|
|
|
|
|
if (finish_command(&child) || err) {
|
|
|
|
strbuf_release(&buf);
|
|
|
|
remove_tempfile();
|
|
|
|
return NULL;
|
|
|
|
}
|
diff: refactor tempfile cleanup handling
There are two pieces of code that create tempfiles for diff:
run_external_diff and run_textconv. The former cleans up its
tempfiles in the face of premature death (i.e., by die() or
by signal), but the latter does not. After this patch, they
will both use the same cleanup routines.
To make clear what the change is, let me first explain what
happens now:
- run_external_diff uses a static global array of 2
diff_tempfile structs (since it knows it will always
need exactly 2 tempfiles). It calls prepare_temp_file
(which doesn't know anything about the global array) on
each of the structs, creating the tempfiles that need to
be cleaned up. It then registers atexit and signal
handlers to look through the global array and remove the
tempfiles. If it succeeds, it calls the handler manually
(which marks the tempfile structs as unused).
- textconv has its own tempfile struct, which it allocates
using prepare_temp_file and cleans up manually. No
signal or atexit handlers.
The new code moves the installation of cleanup handlers into
the prepare_temp_file function. Which means that that
function now has to understand that there is static tempfile
storage. So what happens now is:
- run_external_diff calls prepare_temp_file
- prepare_temp_file calls claim_diff_tempfile, which
allocates an unused slot from our global array
- prepare_temp_file installs (if they have not already
been installed) atexit and signal handlers for cleanup
- prepare_temp_file sets up the tempfile as usual
- prepare_temp_file returns a pointer to the allocated
tempfile
The advantage being that run_external_diff no longer has to
care about setting up cleanup handlers. Now by virtue of
calling prepare_temp_file, run_textconv gets the same
benefit, as will any future users of prepare_temp_file.
There are also a few side benefits to the specific
implementation:
- we now install cleanup handlers _before_ allocating the
tempfile, closing a race which could leave temp cruft
- when allocating a slot in the global array, we will now
detect a situation where the old slots were not properly
vacated (i.e., somebody forgot to call remove upon
leaving the function). In the old code, such a situation
would silently overwrite the tempfile names, meaning we
would forget to clean them up. The new code dies with a
bug warning.
- we make sure only to install the signal handler once.
This isn't a big deal, since we are just overwriting the
old handler, but will become an issue when a later patch
converts the code to use sigchain
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 13:59:56 +08:00
|
|
|
remove_tempfile();
|
2008-10-06 05:43:45 +08:00
|
|
|
|
|
|
|
return strbuf_detach(&buf, outsize);
|
|
|
|
}
|
2010-04-02 08:09:26 +08:00
|
|
|
|
2018-09-21 23:57:22 +08:00
|
|
|
size_t fill_textconv(struct repository *r,
|
|
|
|
struct userdiff_driver *driver,
|
2010-06-07 23:23:36 +08:00
|
|
|
struct diff_filespec *df,
|
|
|
|
char **outbuf)
|
2010-04-02 08:09:26 +08:00
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
|
2016-02-23 02:28:54 +08:00
|
|
|
if (!driver) {
|
2010-04-02 08:09:26 +08:00
|
|
|
if (!DIFF_FILE_VALID(df)) {
|
|
|
|
*outbuf = "";
|
|
|
|
return 0;
|
|
|
|
}
|
2020-04-08 06:11:41 +08:00
|
|
|
if (diff_populate_filespec(r, df, NULL))
|
2010-04-02 08:09:26 +08:00
|
|
|
die("unable to read files to diff");
|
|
|
|
*outbuf = df->data;
|
|
|
|
return df->size;
|
|
|
|
}
|
|
|
|
|
2016-02-23 02:28:54 +08:00
|
|
|
if (!driver->textconv)
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("fill_textconv called with non-textconv driver");
|
2016-02-23 02:28:54 +08:00
|
|
|
|
2016-06-25 07:09:24 +08:00
|
|
|
if (driver->textconv_cache && df->oid_valid) {
|
2016-06-25 07:09:23 +08:00
|
|
|
*outbuf = notes_cache_get(driver->textconv_cache,
|
2017-05-07 06:09:58 +08:00
|
|
|
&df->oid,
|
2010-04-02 08:12:15 +08:00
|
|
|
&size);
|
|
|
|
if (*outbuf)
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:19 +08:00
|
|
|
*outbuf = run_textconv(r, driver->textconv, df, &size);
|
2010-04-02 08:09:26 +08:00
|
|
|
if (!*outbuf)
|
|
|
|
die("unable to read files to diff");
|
2010-04-02 08:12:15 +08:00
|
|
|
|
2016-06-25 07:09:24 +08:00
|
|
|
if (driver->textconv_cache && df->oid_valid) {
|
2010-04-02 08:12:15 +08:00
|
|
|
/* ignore errors, as we might be in a readonly repository */
|
2017-05-07 06:09:58 +08:00
|
|
|
notes_cache_put(driver->textconv_cache, &df->oid, *outbuf,
|
2010-04-02 08:12:15 +08:00
|
|
|
size);
|
|
|
|
/*
|
|
|
|
* we could save up changes and flush them all at the end,
|
|
|
|
* but we would need an extra call after all diffing is done.
|
|
|
|
* Since generating a cache entry is the slow path anyway,
|
|
|
|
* this extra overhead probably isn't a big deal.
|
|
|
|
*/
|
|
|
|
notes_cache_write(driver->textconv_cache);
|
|
|
|
}
|
|
|
|
|
2010-04-02 08:09:26 +08:00
|
|
|
return size;
|
|
|
|
}
|
2012-10-26 23:53:52 +08:00
|
|
|
|
2018-09-21 23:57:22 +08:00
|
|
|
int textconv_object(struct repository *r,
|
|
|
|
const char *path,
|
2017-05-24 13:15:10 +08:00
|
|
|
unsigned mode,
|
|
|
|
const struct object_id *oid,
|
|
|
|
int oid_valid,
|
|
|
|
char **buf,
|
|
|
|
unsigned long *buf_size)
|
|
|
|
{
|
|
|
|
struct diff_filespec *df;
|
|
|
|
struct userdiff_driver *textconv;
|
|
|
|
|
|
|
|
df = alloc_filespec(path);
|
2017-06-20 03:38:44 +08:00
|
|
|
fill_filespec(df, oid, oid_valid, mode);
|
2018-11-10 13:49:06 +08:00
|
|
|
textconv = get_textconv(r, df);
|
2017-05-24 13:15:10 +08:00
|
|
|
if (!textconv) {
|
|
|
|
free_filespec(df);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-21 23:57:22 +08:00
|
|
|
*buf_size = fill_textconv(r, textconv, df, buf);
|
2017-05-24 13:15:10 +08:00
|
|
|
free_filespec(df);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-10-26 23:53:52 +08:00
|
|
|
void setup_diff_pager(struct diff_options *opt)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If the user asked for our exit code, then either they want --quiet
|
|
|
|
* or --exit-code. We should definitely not bother with a pager in the
|
|
|
|
* former case, as we will generate no output. Since we still properly
|
|
|
|
* report our exit code even when a pager is run, we _could_ run a
|
|
|
|
* pager with --exit-code. But since we have not done so historically,
|
|
|
|
* and because it is easy to find people oneline advising "git diff
|
|
|
|
* --exit-code" in hooks and other scripts, we do not do so.
|
|
|
|
*/
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!opt->flags.exit_with_status &&
|
2012-10-26 23:53:52 +08:00
|
|
|
check_pager_config("diff") != 0)
|
|
|
|
setup_pager();
|
|
|
|
}
|