2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
|
|
|
#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"
|
2008-10-06 05:43:21 +08:00
|
|
|
#include "userdiff.h"
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 14:02:35 +08:00
|
|
|
#include "sigchain.h"
|
2009-10-19 20:38:32 +08:00
|
|
|
#include "submodule.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"
|
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;
|
2011-02-19 18:21:28 +08:00
|
|
|
static int diff_rename_limit_default = 400;
|
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;
|
2012-09-28 03:12:52 +08:00
|
|
|
static int diff_context_default = 3;
|
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;
|
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;
|
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;
|
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,
|
|
|
|
GIT_COLOR_NORMAL, /* PLAIN */
|
|
|
|
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 */
|
2006-06-14 00:45:44 +08:00
|
|
|
};
|
|
|
|
|
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
|
|
|
static int parse_diff_color_slot(const char *var, int ofs)
|
|
|
|
{
|
|
|
|
if (!strcasecmp(var+ofs, "plain"))
|
|
|
|
return DIFF_PLAIN;
|
|
|
|
if (!strcasecmp(var+ofs, "meta"))
|
|
|
|
return DIFF_METAINFO;
|
|
|
|
if (!strcasecmp(var+ofs, "frag"))
|
|
|
|
return DIFF_FRAGINFO;
|
|
|
|
if (!strcasecmp(var+ofs, "old"))
|
|
|
|
return DIFF_FILE_OLD;
|
|
|
|
if (!strcasecmp(var+ofs, "new"))
|
|
|
|
return DIFF_FILE_NEW;
|
2006-07-23 17:24:18 +08:00
|
|
|
if (!strcasecmp(var+ofs, "commit"))
|
|
|
|
return DIFF_COMMIT;
|
2006-09-23 13:48:39 +08:00
|
|
|
if (!strcasecmp(var+ofs, "whitespace"))
|
|
|
|
return DIFF_WHITESPACE;
|
2009-11-27 14:55:18 +08:00
|
|
|
if (!strcasecmp(var+ofs, "func"))
|
|
|
|
return DIFF_FUNCINFO;
|
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
|
|
|
return -1;
|
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")) {
|
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
|
|
|
DIFF_OPT_CLR(options, DIRSTAT_BY_LINE);
|
|
|
|
DIFF_OPT_CLR(options, DIRSTAT_BY_FILE);
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "lines")) {
|
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
|
|
|
DIFF_OPT_SET(options, DIRSTAT_BY_LINE);
|
2011-04-29 17:36:18 +08:00
|
|
|
DIFF_OPT_CLR(options, DIRSTAT_BY_FILE);
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "files")) {
|
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
|
|
|
DIFF_OPT_CLR(options, DIRSTAT_BY_LINE);
|
2011-04-29 17:36:18 +08:00
|
|
|
DIFF_OPT_SET(options, DIRSTAT_BY_FILE);
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "noncumulative")) {
|
2011-04-29 17:36:18 +08:00
|
|
|
DIFF_OPT_CLR(options, DIRSTAT_CUMULATIVE);
|
2012-10-29 00:50:54 +08:00
|
|
|
} else if (!strcmp(p, "cumulative")) {
|
2011-04-29 17:36:18 +08:00
|
|
|
DIFF_OPT_SET(options, DIRSTAT_CUMULATIVE);
|
|
|
|
} 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"))
|
|
|
|
DIFF_OPT_SET(options, SUBMODULE_LOG);
|
|
|
|
else if (!strcmp(value, "short"))
|
|
|
|
DIFF_OPT_CLR(options, SUBMODULE_LOG);
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-10 02:46:15 +08:00
|
|
|
static int git_config_rename(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
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;
|
|
|
|
}
|
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;
|
|
|
|
}
|
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;
|
|
|
|
}
|
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);
|
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;
|
|
|
|
}
|
|
|
|
|
2011-08-18 13:05:08 +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
|
|
|
{
|
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
|
|
|
|
2007-02-20 17:55:07 +08:00
|
|
|
if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
|
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
|
|
|
int slot = parse_diff_color_slot(var, 11);
|
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);
|
2006-09-08 16:03:18 +08:00
|
|
|
color_parse(value, var, 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
|
|
|
return 0;
|
|
|
|
}
|
2007-04-23 08:52:55 +08:00
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2010-08-06 06:39:25 +08:00
|
|
|
if (!prefixcmp(var, "submodule."))
|
|
|
|
return parse_submodule_config_option(var, value);
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
int need_one = quote_c_style(one, NULL, NULL, 1);
|
|
|
|
int need_two = quote_c_style(two, NULL, NULL, 1);
|
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, '"');
|
|
|
|
quote_c_style(one, &res, NULL, 1);
|
|
|
|
quote_c_style(two, &res, NULL, 1);
|
|
|
|
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;
|
|
|
|
external_diff_cmd = 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct diff_tempfile {
|
|
|
|
const char *name; /* filename external diff should read from */
|
|
|
|
char hex[41];
|
|
|
|
char mode[10];
|
2007-05-20 21:35:46 +08:00
|
|
|
char tmp_path[PATH_MAX];
|
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
|
|
|
typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
|
|
|
|
|
|
|
|
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;
|
|
|
|
sane_truncate_fn truncate;
|
|
|
|
const char **label_path;
|
|
|
|
struct diff_words_data *diff_words;
|
2010-05-26 15:08:02 +08:00
|
|
|
struct diff_options *opt;
|
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 *found_changesp;
|
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;
|
|
|
|
}
|
|
|
|
|
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 fill_mmfile(mmfile_t *mf, struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one)) {
|
|
|
|
mf->ptr = (char *)""; /* does not matter */
|
|
|
|
mf->size = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else if (diff_populate_filespec(one, 0))
|
|
|
|
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 */
|
|
|
|
static unsigned long diff_filespec_size(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one))
|
|
|
|
return 0;
|
|
|
|
diff_populate_filespec(one, 1);
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2010-05-26 15:08:02 +08:00
|
|
|
static void emit_line_0(struct diff_options *o, const char *set, 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;
|
2009-09-15 09:44:01 +08:00
|
|
|
int nofirst;
|
2010-05-26 15:08:02 +08:00
|
|
|
FILE *file = o->file;
|
|
|
|
|
|
|
|
if (o->output_prefix) {
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
msg = o->output_prefix(o, o->output_prefix_data);
|
|
|
|
assert(msg);
|
|
|
|
fwrite(msg->buf, msg->len, 1, 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
|
|
|
|
2009-09-15 09:44:01 +08:00
|
|
|
if (len == 0) {
|
|
|
|
has_trailing_newline = (first == '\n');
|
|
|
|
has_trailing_carriage_return = (!has_trailing_newline &&
|
|
|
|
(first == '\r'));
|
|
|
|
nofirst = has_trailing_newline || has_trailing_carriage_return;
|
|
|
|
} else {
|
|
|
|
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--;
|
|
|
|
nofirst = 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
|
|
|
|
2009-11-28 14:04:10 +08:00
|
|
|
if (len || !nofirst) {
|
|
|
|
fputs(set, file);
|
|
|
|
if (!nofirst)
|
|
|
|
fputc(first, file);
|
|
|
|
fwrite(line, len, 1, file);
|
|
|
|
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)
|
|
|
|
{
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(o, set, reset, line[0], line+1, len-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
|
|
|
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
|
|
|
}
|
|
|
|
|
2009-09-15 09:44:01 +08:00
|
|
|
static void emit_add_line(const char *reset,
|
|
|
|
struct emit_callback *ecbdata,
|
|
|
|
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
|
|
|
{
|
|
|
|
const char *ws = diff_get_color(ecbdata->color_diff, DIFF_WHITESPACE);
|
|
|
|
const char *set = diff_get_color(ecbdata->color_diff, DIFF_FILE_NEW);
|
|
|
|
|
|
|
|
if (!*ws)
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(ecbdata->opt, set, reset, '+', 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 if (new_blank_line_at_eof(ecbdata, line, len))
|
|
|
|
/* Blank line at EOF - paint '+' as well */
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(ecbdata->opt, ws, reset, '+', 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. */
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(ecbdata->opt, set, reset, '+', "", 0);
|
2009-09-15 09:44:01 +08:00
|
|
|
ws_check_emit(line, len, ecbdata->ws_rule,
|
2010-05-26 15:08:02 +08:00
|
|
|
ecbdata->opt->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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-11-27 14:55:18 +08:00
|
|
|
static void emit_hunk_header(struct emit_callback *ecbdata,
|
|
|
|
const char *line, int len)
|
|
|
|
{
|
|
|
|
const char *plain = diff_get_color(ecbdata->color_diff, DIFF_PLAIN);
|
|
|
|
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);
|
|
|
|
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))) {
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line(ecbdata->opt, plain, reset, line, len);
|
2009-11-27 14:55:18 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
ep += 2; /* skip over @@ */
|
|
|
|
|
|
|
|
/* The hunk header in fraginfo color */
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_add(&msgbuf, frag, strlen(frag));
|
|
|
|
strbuf_add(&msgbuf, line, ep - line);
|
|
|
|
strbuf_add(&msgbuf, reset, strlen(reset));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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) {
|
|
|
|
strbuf_add(&msgbuf, plain, strlen(plain));
|
|
|
|
strbuf_add(&msgbuf, cp, ep - cp);
|
|
|
|
strbuf_add(&msgbuf, reset, strlen(reset));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ep < line + len) {
|
|
|
|
strbuf_add(&msgbuf, func, strlen(func));
|
|
|
|
strbuf_add(&msgbuf, ep, line + len - ep);
|
|
|
|
strbuf_add(&msgbuf, reset, strlen(reset));
|
|
|
|
}
|
2009-11-27 14:55:18 +08:00
|
|
|
|
2010-05-29 23:32:05 +08:00
|
|
|
strbuf_add(&msgbuf, line + len, org_len - len);
|
|
|
|
emit_line(ecbdata->opt, "", "", msgbuf.buf, msgbuf.len);
|
|
|
|
strbuf_release(&msgbuf);
|
2009-11-27 14:55:18 +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
|
|
|
static struct diff_tempfile *claim_diff_tempfile(void) {
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_temp); i++)
|
|
|
|
if (!diff_temp[i].name)
|
|
|
|
return diff_temp + i;
|
|
|
|
die("BUG: diff is failing to clean up its tempfiles");
|
|
|
|
}
|
|
|
|
|
|
|
|
static int remove_tempfile_installed;
|
|
|
|
|
|
|
|
static void remove_tempfile(void)
|
|
|
|
{
|
|
|
|
int i;
|
2009-02-12 21:36:14 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_temp); i++) {
|
|
|
|
if (diff_temp[i].name == diff_temp[i].tmp_path)
|
2009-04-30 05:22:56 +08:00
|
|
|
unlink_or_warn(diff_temp[i].name);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
static void remove_tempfile_on_signal(int signo)
|
|
|
|
{
|
|
|
|
remove_tempfile();
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 14:02:35 +08:00
|
|
|
sigchain_pop(signo);
|
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
|
|
|
raise(signo);
|
|
|
|
}
|
|
|
|
|
2008-03-10 10:43:39 +08:00
|
|
|
static void print_line_count(FILE *file, int count)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
switch (count) {
|
|
|
|
case 0:
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, "0,0");
|
2006-04-22 14:57:45 +08:00
|
|
|
break;
|
|
|
|
case 1:
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, "1");
|
2006-04-22 14:57:45 +08:00
|
|
|
break;
|
|
|
|
default:
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, "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;
|
|
|
|
static const char *nneof = " No newline at end of file\n";
|
|
|
|
const char *old = diff_get_color(ecb->color_diff, DIFF_FILE_OLD);
|
|
|
|
const char *reset = diff_get_color(ecb->color_diff, DIFF_RESET);
|
|
|
|
|
|
|
|
while (0 < size) {
|
|
|
|
int len;
|
|
|
|
|
|
|
|
endp = memchr(data, '\n', size);
|
|
|
|
len = endp ? (endp - data + 1) : size;
|
|
|
|
if (prefix != '+') {
|
|
|
|
ecb->lno_in_preimage++;
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(ecb->opt, old, reset, '-',
|
2009-09-15 09:44:01 +08:00
|
|
|
data, len);
|
|
|
|
} else {
|
|
|
|
ecb->lno_in_postimage++;
|
|
|
|
emit_add_line(reset, ecb, data, len);
|
2007-02-20 22:08:46 +08:00
|
|
|
}
|
2009-09-15 09:44:01 +08:00
|
|
|
size -= len;
|
|
|
|
data += len;
|
|
|
|
}
|
|
|
|
if (!endp) {
|
|
|
|
const char *plain = diff_get_color(ecb->color_diff,
|
|
|
|
DIFF_PLAIN);
|
2012-08-05 05:07:35 +08:00
|
|
|
putc('\n', ecb->opt->file);
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line_0(ecb->opt, plain, reset, '\\',
|
2009-09-15 09:44:01 +08:00
|
|
|
nneof, strlen(nneof));
|
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;
|
2006-09-23 07:17:58 +08:00
|
|
|
const char *name_a_tab, *name_b_tab;
|
2011-08-18 13:03:12 +08:00
|
|
|
const char *metainfo = diff_get_color(o->use_color, DIFF_METAINFO);
|
|
|
|
const char *fraginfo = diff_get_color(o->use_color, DIFF_FRAGINFO);
|
|
|
|
const char *reset = diff_get_color(o->use_color, DIFF_RESET);
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
char *line_prefix = "";
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
|
|
|
|
if (o && o->output_prefix) {
|
|
|
|
msgbuf = o->output_prefix(o, o->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
2008-08-19 11:08:09 +08:00
|
|
|
|
|
|
|
if (diff_mnemonic_prefix && DIFF_OPT_TST(o, REVERSE_DIFF)) {
|
|
|
|
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
|
|
|
name_a_tab = strchr(name_a, ' ') ? "\t" : "";
|
|
|
|
name_b_tab = strchr(name_b, ' ') ? "\t" : "";
|
|
|
|
|
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
|
|
|
|
2010-04-02 08:09:26 +08:00
|
|
|
size_one = fill_textconv(textconv_one, one, &data_one);
|
|
|
|
size_two = fill_textconv(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);
|
2009-09-16 02:21:10 +08:00
|
|
|
ecbdata.found_changesp = &o->found_changes;
|
|
|
|
ecbdata.ws_rule = whitespace_rule(name_b ? name_b : name_a);
|
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);
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(o->file,
|
2010-05-26 15:23:54 +08:00
|
|
|
"%s%s--- %s%s%s\n%s%s+++ %s%s%s\n%s%s@@ -",
|
|
|
|
line_prefix, metainfo, a_name.buf, name_a_tab, reset,
|
|
|
|
line_prefix, metainfo, b_name.buf, name_b_tab, reset,
|
|
|
|
line_prefix, fraginfo);
|
2011-03-01 08:11:55 +08:00
|
|
|
if (!o->irreversible_delete)
|
|
|
|
print_line_count(o->file, lc_a);
|
|
|
|
else
|
|
|
|
fprintf(o->file, "?,?");
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(o->file, " +");
|
|
|
|
print_line_count(o->file, lc_b);
|
|
|
|
fprintf(o->file, " @@%s\n", reset);
|
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;
|
|
|
|
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;
|
|
|
|
struct diff_words_style_elem new, old, ctx;
|
|
|
|
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
|
|
|
};
|
|
|
|
|
2010-04-14 23:59:06 +08:00
|
|
|
static int fn_out_diff_words_write_helper(FILE *fp,
|
|
|
|
struct diff_words_style_elem *st_el,
|
|
|
|
const char *newline,
|
2010-05-29 23:32:06 +08:00
|
|
|
size_t count, const char *buf,
|
|
|
|
const char *line_prefix)
|
2010-04-14 23:59:06 +08:00
|
|
|
{
|
2010-05-29 23:32:06 +08:00
|
|
|
int print = 0;
|
|
|
|
|
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)
|
|
|
|
fputs(line_prefix, fp);
|
2010-04-14 23:59:06 +08:00
|
|
|
if (p != buf) {
|
|
|
|
if (st_el->color && fputs(st_el->color, fp) < 0)
|
|
|
|
return -1;
|
|
|
|
if (fputs(st_el->prefix, fp) < 0 ||
|
|
|
|
fwrite(buf, p ? p - buf : count, 1, fp) != 1 ||
|
|
|
|
fputs(st_el->suffix, fp) < 0)
|
|
|
|
return -1;
|
|
|
|
if (st_el->color && *st_el->color
|
|
|
|
&& fputs(GIT_COLOR_RESET, fp) < 0)
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (!p)
|
|
|
|
return 0;
|
|
|
|
if (fputs(newline, fp) < 0)
|
|
|
|
return -1;
|
|
|
|
count -= p + 1 - buf;
|
|
|
|
buf = p + 1;
|
2010-05-29 23:32:06 +08:00
|
|
|
print = 1;
|
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:
|
|
|
|
*
|
|
|
|
* 1. collect a the minus/plus lines of a diff hunk, divided into
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-29 05:56:15 +08:00
|
|
|
static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
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
|
|
|
int minus_first, minus_len, plus_first, plus_len;
|
|
|
|
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;
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
char *line_prefix = "";
|
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
|
|
|
if (line[0] != '@' || parse_hunk_header(line, len,
|
|
|
|
&minus_first, &minus_len, &plus_first, &plus_len))
|
2006-07-29 05:56:15 +08:00
|
|
|
return;
|
|
|
|
|
2010-05-29 23:32:06 +08:00
|
|
|
assert(opt);
|
|
|
|
if (opt->output_prefix) {
|
|
|
|
msgbuf = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
|
|
|
|
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) {
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt->file,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->ctx, style->newline,
|
|
|
|
plus_begin - diff_words->current_plus,
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->current_plus, line_prefix);
|
|
|
|
if (*(plus_begin - 1) == '\n')
|
|
|
|
fputs(line_prefix, diff_words->opt->file);
|
|
|
|
}
|
|
|
|
if (minus_begin != minus_end) {
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt->file,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->old, style->newline,
|
2010-05-29 23:32:06 +08:00
|
|
|
minus_end - minus_begin, minus_begin,
|
|
|
|
line_prefix);
|
|
|
|
}
|
|
|
|
if (plus_begin != plus_end) {
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt->file,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->new, style->newline,
|
2010-05-29 23:32:06 +08:00
|
|
|
plus_end - plus_begin, plus_begin,
|
|
|
|
line_prefix);
|
|
|
|
}
|
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)
|
|
|
|
{
|
|
|
|
if (word_regex && *begin < buffer->size) {
|
|
|
|
regmatch_t match[1];
|
|
|
|
if (!regexec(word_regex, buffer->ptr + *begin, 1, match, 0)) {
|
|
|
|
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;
|
|
|
|
return *begin >= *end;
|
|
|
|
}
|
|
|
|
return -1;
|
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;
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
char *line_prefix = "";
|
|
|
|
|
|
|
|
assert(opt);
|
|
|
|
if (opt->output_prefix) {
|
|
|
|
msgbuf = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
|
|
|
|
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) {
|
2010-05-29 23:32:06 +08:00
|
|
|
fputs(line_prefix, diff_words->opt->file);
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt->file,
|
2010-04-14 23:59:06 +08:00
|
|
|
&style->old, style->newline,
|
2010-05-29 23:32:06 +08:00
|
|
|
diff_words->minus.text.size,
|
|
|
|
diff_words->minus.text.ptr, line_prefix);
|
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;
|
2008-08-14 14:18:22 +08:00
|
|
|
xdi_diff_outf(&minus, &plus, fn_out_diff_words_aux, diff_words,
|
2010-05-05 04:41:34 +08:00
|
|
|
&xpp, &xecfg);
|
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))
|
|
|
|
fputs(line_prefix, diff_words->opt->file);
|
|
|
|
fn_out_diff_words_write_helper(diff_words->opt->file,
|
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
|
2010-05-29 23:32:06 +08:00
|
|
|
- diff_words->current_plus, diff_words->current_plus,
|
|
|
|
line_prefix);
|
|
|
|
}
|
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)
|
|
|
|
{
|
|
|
|
if (ecbdata->diff_words->minus.text.size ||
|
|
|
|
ecbdata->diff_words->plus.text.size)
|
|
|
|
diff_words_show(ecbdata->diff_words);
|
|
|
|
}
|
|
|
|
|
2012-03-15 02:24:08 +08:00
|
|
|
static void diff_filespec_load_driver(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
/* Use already-loaded driver */
|
|
|
|
if (one->driver)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (S_ISREG(one->mode))
|
|
|
|
one->driver = userdiff_find_by_path(one->path);
|
|
|
|
|
|
|
|
/* Fallback to default settings */
|
|
|
|
if (!one->driver)
|
|
|
|
one->driver = userdiff_find_by_name("default");
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *userdiff_word_regex(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
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
|
|
|
|
|
|
|
ecbdata->diff_words =
|
|
|
|
xcalloc(1, sizeof(struct diff_words_data));
|
|
|
|
ecbdata->diff_words->type = o->word_diff;
|
|
|
|
ecbdata->diff_words->opt = o;
|
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = userdiff_word_regex(one);
|
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = userdiff_word_regex(two);
|
|
|
|
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))
|
|
|
|
die ("Invalid regular expression: %s",
|
|
|
|
o->word_regex);
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
st->old.color = diff_get_color_opt(o, DIFF_FILE_OLD);
|
|
|
|
st->new.color = diff_get_color_opt(o, DIFF_FILE_NEW);
|
|
|
|
st->ctx.color = diff_get_color_opt(o, DIFF_PLAIN);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
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);
|
|
|
|
}
|
2006-07-29 05:56:15 +08:00
|
|
|
free(ecbdata->diff_words);
|
|
|
|
ecbdata->diff_words = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2008-01-02 17:50:11 +08:00
|
|
|
static unsigned long sane_truncate_line(struct emit_callback *ecb, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
const char *cp;
|
|
|
|
unsigned long allot;
|
|
|
|
size_t l = len;
|
|
|
|
|
|
|
|
if (ecb->truncate)
|
|
|
|
return ecb->truncate(line, 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
|
|
|
}
|
|
|
|
|
2006-06-14 00:45:44 +08:00
|
|
|
static void fn_out_consume(void *priv, char *line, unsigned long len)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct emit_callback *ecbdata = priv;
|
2008-01-17 23:03:06 +08:00
|
|
|
const char *meta = diff_get_color(ecbdata->color_diff, DIFF_METAINFO);
|
|
|
|
const char *plain = diff_get_color(ecbdata->color_diff, DIFF_PLAIN);
|
2006-07-23 17:24:18 +08:00
|
|
|
const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);
|
2010-05-26 15:23:54 +08:00
|
|
|
struct diff_options *o = ecbdata->opt;
|
|
|
|
char *line_prefix = "";
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
|
|
|
|
if (o && o->output_prefix) {
|
|
|
|
msgbuf = o->output_prefix(o, o->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2009-11-20 05:12:24 +08:00
|
|
|
if (ecbdata->header) {
|
2010-05-26 15:08:02 +08:00
|
|
|
fprintf(ecbdata->opt->file, "%s", ecbdata->header->buf);
|
2009-11-20 05:12:24 +08:00
|
|
|
strbuf_reset(ecbdata->header);
|
|
|
|
ecbdata->header = NULL;
|
|
|
|
}
|
2007-02-26 06:34:54 +08:00
|
|
|
*(ecbdata->found_changesp) = 1;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (ecbdata->label_path[0]) {
|
2006-09-23 07:17:58 +08:00
|
|
|
const char *name_a_tab, *name_b_tab;
|
|
|
|
|
|
|
|
name_a_tab = strchr(ecbdata->label_path[0], ' ') ? "\t" : "";
|
|
|
|
name_b_tab = strchr(ecbdata->label_path[1], ' ') ? "\t" : "";
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(ecbdata->opt->file, "%s%s--- %s%s%s\n",
|
|
|
|
line_prefix, meta, ecbdata->label_path[0], reset, name_a_tab);
|
|
|
|
fprintf(ecbdata->opt->file, "%s%s+++ %s%s%s\n",
|
|
|
|
line_prefix, meta, ecbdata->label_path[1], reset, name_b_tab);
|
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);
|
2008-01-02 17:50:11 +08:00
|
|
|
len = sane_truncate_line(ecbdata, 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);
|
2008-01-02 17:50:11 +08:00
|
|
|
if (line[len-1] != '\n')
|
2010-05-26 15:08:02 +08:00
|
|
|
putc('\n', ecbdata->opt->file);
|
2006-09-23 13:48:39 +08:00
|
|
|
return;
|
2006-06-14 00:45:44 +08:00
|
|
|
}
|
2006-09-23 13:48:39 +08:00
|
|
|
|
2009-09-04 14:59:25 +08:00
|
|
|
if (len < 1) {
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line(ecbdata->opt, reset, reset, line, len);
|
2010-04-14 23:59:06 +08:00
|
|
|
if (ecbdata->diff_words
|
|
|
|
&& ecbdata->diff_words->type == DIFF_WORDS_PORCELAIN)
|
2010-05-26 15:08:02 +08:00
|
|
|
fputs("~\n", ecbdata->opt->file);
|
2006-09-23 13:48:39 +08:00
|
|
|
return;
|
2006-06-14 00:45:44 +08:00
|
|
|
}
|
2006-09-23 13:48:39 +08:00
|
|
|
|
|
|
|
if (ecbdata->diff_words) {
|
|
|
|
if (line[0] == '-') {
|
|
|
|
diff_words_append(line, len,
|
|
|
|
&ecbdata->diff_words->minus);
|
|
|
|
return;
|
|
|
|
} else if (line[0] == '+') {
|
|
|
|
diff_words_append(line, len,
|
|
|
|
&ecbdata->diff_words->plus);
|
|
|
|
return;
|
2012-01-12 19:15:33 +08:00
|
|
|
} else if (!prefixcmp(line, "\\ ")) {
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
return;
|
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);
|
2010-04-14 23:59:06 +08:00
|
|
|
if (ecbdata->diff_words->type == DIFF_WORDS_PORCELAIN) {
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line(ecbdata->opt, plain, reset, line, len);
|
|
|
|
fputs("~\n", ecbdata->opt->file);
|
2010-04-14 23:59:06 +08:00
|
|
|
} else {
|
2011-05-21 01:20:12 +08:00
|
|
|
/*
|
|
|
|
* Skip the prefix character, if any. With
|
|
|
|
* diff_suppress_blank_empty, there may be
|
|
|
|
* none.
|
|
|
|
*/
|
|
|
|
if (line[0] != '\n') {
|
|
|
|
line++;
|
|
|
|
len--;
|
|
|
|
}
|
|
|
|
emit_line(ecbdata->opt, plain, reset, line, len);
|
2010-04-14 23:59:06 +08:00
|
|
|
}
|
2006-09-23 13:48:39 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-09-04 15:41:15 +08:00
|
|
|
if (line[0] != '+') {
|
|
|
|
const char *color =
|
|
|
|
diff_get_color(ecbdata->color_diff,
|
|
|
|
line[0] == '-' ? DIFF_FILE_OLD : DIFF_PLAIN);
|
|
|
|
ecbdata->lno_in_preimage++;
|
2009-09-15 13:05:57 +08:00
|
|
|
if (line[0] == ' ')
|
|
|
|
ecbdata->lno_in_postimage++;
|
2010-05-26 15:08:02 +08:00
|
|
|
emit_line(ecbdata->opt, color, reset, line, len);
|
2009-09-15 13:05:57 +08:00
|
|
|
} else {
|
|
|
|
ecbdata->lno_in_postimage++;
|
2009-09-15 09:44:01 +08:00
|
|
|
emit_add_line(reset, ecbdata, line + 1, len - 1);
|
2006-09-23 13:48:39 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *pprint_rename(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
const char *old = a;
|
|
|
|
const char *new = b;
|
2008-10-10 03:12:12 +08:00
|
|
|
struct strbuf name = STRBUF_INIT;
|
2006-04-22 14:57:45 +08:00
|
|
|
int pfx_length, sfx_length;
|
|
|
|
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) {
|
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
|
|
|
quote_c_style(a, &name, NULL, 0);
|
|
|
|
strbuf_addstr(&name, " => ");
|
|
|
|
quote_c_style(b, &name, NULL, 0);
|
2007-09-27 18:58:23 +08:00
|
|
|
return strbuf_detach(&name, NULL);
|
2007-02-10 22:39:00 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
/* Find common prefix */
|
|
|
|
pfx_length = 0;
|
|
|
|
while (*old && *new && *old == *new) {
|
|
|
|
if (*old == '/')
|
|
|
|
pfx_length = old - a + 1;
|
|
|
|
old++;
|
|
|
|
new++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find common suffix */
|
|
|
|
old = a + len_a;
|
|
|
|
new = b + len_b;
|
|
|
|
sfx_length = 0;
|
|
|
|
while (a <= old && b <= new && *old == *new) {
|
|
|
|
if (*old == '/')
|
|
|
|
sfx_length = len_a - (old - a);
|
|
|
|
old--;
|
|
|
|
new--;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
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) {
|
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_add(&name, a, pfx_length);
|
|
|
|
strbuf_addch(&name, '{');
|
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_add(&name, a + pfx_length, a_midlen);
|
|
|
|
strbuf_addstr(&name, " => ");
|
|
|
|
strbuf_add(&name, b + pfx_length, b_midlen);
|
|
|
|
if (pfx_length + sfx_length) {
|
|
|
|
strbuf_addch(&name, '}');
|
|
|
|
strbuf_add(&name, a + len_a - sfx_length, sfx_length);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2007-09-27 18:58:23 +08:00
|
|
|
return strbuf_detach(&name, NULL);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct diffstat_t {
|
|
|
|
int nr;
|
|
|
|
int alloc;
|
|
|
|
struct diffstat_file {
|
2007-12-12 15:46:30 +08:00
|
|
|
char *from_name;
|
2006-04-22 14:57:45 +08:00
|
|
|
char *name;
|
2007-12-12 15:46:30 +08:00
|
|
|
char *print_name;
|
2006-04-22 14:57:45 +08:00
|
|
|
unsigned is_unmerged:1;
|
|
|
|
unsigned is_binary:1;
|
|
|
|
unsigned is_renamed:1;
|
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
|
|
|
unsigned is_interesting:1;
|
2010-04-18 01:41:08 +08:00
|
|
|
uintmax_t added, deleted;
|
2006-04-22 14:57:45 +08:00
|
|
|
} **files;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct diffstat_file *diffstat_add(struct diffstat_t *diffstat,
|
|
|
|
const char *name_a,
|
|
|
|
const char *name_b)
|
|
|
|
{
|
|
|
|
struct diffstat_file *x;
|
|
|
|
x = xcalloc(sizeof (*x), 1);
|
|
|
|
if (diffstat->nr == diffstat->alloc) {
|
|
|
|
diffstat->alloc = alloc_nr(diffstat->alloc);
|
|
|
|
diffstat->files = xrealloc(diffstat->files,
|
|
|
|
diffstat->alloc * sizeof(x));
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void diffstat_consume(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
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++;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
* scale linearly as if the alloted width is one column shorter
|
|
|
|
* 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
|
|
|
}
|
|
|
|
|
2008-03-10 10:43:39 +08:00
|
|
|
static void show_name(FILE *file,
|
2009-04-25 06:06:47 +08:00
|
|
|
const char *prefix, const char *name, int len)
|
2006-09-27 09:53:02 +08:00
|
|
|
{
|
2009-04-25 06:06:47 +08:00
|
|
|
fprintf(file, " %s%-*s |", prefix, len, name);
|
2006-09-27 09:53:02 +08:00
|
|
|
}
|
|
|
|
|
2008-03-10 10:43:39 +08:00
|
|
|
static void show_graph(FILE *file, char ch, int cnt, const char *set, const char *reset)
|
2006-09-27 09:53:02 +08:00
|
|
|
{
|
|
|
|
if (cnt <= 0)
|
|
|
|
return;
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, "%s", set);
|
2006-09-27 09:53:02 +08:00
|
|
|
while (cnt--)
|
2008-03-10 10:43:39 +08:00
|
|
|
putc(ch, file);
|
|
|
|
fprintf(file, "%s", 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)
|
|
|
|
{
|
|
|
|
char *pname;
|
|
|
|
|
|
|
|
if (file->print_name)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!file->is_renamed) {
|
2008-10-10 03:12:12 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2007-12-12 15:46:30 +08:00
|
|
|
if (quote_c_style(file->name, &buf, NULL, 0)) {
|
|
|
|
pname = strbuf_detach(&buf, NULL);
|
|
|
|
} else {
|
|
|
|
pname = file->name;
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
pname = pprint_rename(file->from_name, file->name);
|
|
|
|
}
|
|
|
|
file->print_name = pname;
|
|
|
|
}
|
|
|
|
|
2012-02-01 20:55:07 +08:00
|
|
|
int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
|
|
|
|
{
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!files) {
|
|
|
|
assert(insertions == 0 && deletions == 0);
|
2012-09-13 22:16:26 +08:00
|
|
|
return fprintf(fp, "%s\n", " 0 files changed");
|
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) {
|
|
|
|
/*
|
|
|
|
* TRANSLATORS: "+" in (+) is a line addition marker;
|
|
|
|
* do not translate it.
|
|
|
|
*/
|
|
|
|
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) {
|
|
|
|
/*
|
|
|
|
* TRANSLATORS: "-" in (-) is a line removal marker;
|
|
|
|
* do not translate it.
|
|
|
|
*/
|
|
|
|
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');
|
|
|
|
ret = fputs(sb.buf, fp);
|
|
|
|
strbuf_release(&sb);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
const char *line_prefix = "";
|
2011-05-28 12:50:39 +08:00
|
|
|
int extra_shown = 0;
|
2010-05-26 15:23:54 +08:00
|
|
|
struct strbuf *msg = NULL;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
if (options->output_prefix) {
|
|
|
|
msg = options->output_prefix(options, options->output_prefix_data);
|
|
|
|
line_prefix = msg->buf;
|
|
|
|
}
|
|
|
|
|
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;
|
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
|
|
|
if (!data->files[i]->is_interesting &&
|
2011-05-27 20:36:40 +08:00
|
|
|
(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
|
|
|
}
|
2011-05-27 20:36:41 +08:00
|
|
|
count = i; /* min(count, data->nr) */
|
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
|
|
|
|
* "scaled". If total width is too small to accomodate the
|
|
|
|
* 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)
|
2012-04-16 18:44:51 +08:00
|
|
|
width = term_columns() - options->output_prefix_length;
|
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 = "";
|
2007-12-12 15:46:30 +08:00
|
|
|
char *name = data->files[i]->print_name;
|
2010-04-18 01:41:08 +08:00
|
|
|
uintmax_t added = data->files[i]->added;
|
|
|
|
uintmax_t deleted = data->files[i]->deleted;
|
2006-09-27 09:53:02 +08:00
|
|
|
int name_len;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
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
|
|
|
if (!data->files[i]->is_interesting &&
|
2011-05-27 20:36:40 +08:00
|
|
|
(added + deleted == 0)) {
|
|
|
|
total_files--;
|
|
|
|
continue;
|
|
|
|
}
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (data->files[i]->is_binary) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(options->file, "%s", line_prefix);
|
2009-04-25 06:06:47 +08:00
|
|
|
show_name(options->file, prefix, name, len);
|
2012-05-08 04:29:08 +08:00
|
|
|
fprintf(options->file, " %*s", number_width, "Bin");
|
2012-05-02 01:10:14 +08:00
|
|
|
if (!added && !deleted) {
|
|
|
|
putc('\n', options->file);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
fprintf(options->file, " %s%"PRIuMAX"%s",
|
2010-04-18 01:41:08 +08:00
|
|
|
del_c, deleted, reset);
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(options->file, " -> ");
|
2010-04-18 01:41:08 +08:00
|
|
|
fprintf(options->file, "%s%"PRIuMAX"%s",
|
|
|
|
add_c, added, reset);
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(options->file, " bytes");
|
|
|
|
fprintf(options->file, "\n");
|
2007-12-12 15:46:30 +08:00
|
|
|
continue;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else if (data->files[i]->is_unmerged) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(options->file, "%s", line_prefix);
|
2009-04-25 06:06:47 +08:00
|
|
|
show_name(options->file, prefix, name, len);
|
2012-05-01 04:38:58 +08:00
|
|
|
fprintf(options->file, " Unmerged\n");
|
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;
|
|
|
|
adds += add;
|
|
|
|
dels += del;
|
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
if (graph_width <= max_change) {
|
2012-02-15 05:49:11 +08:00
|
|
|
int total = add + del;
|
|
|
|
|
2012-03-01 20:26:43 +08:00
|
|
|
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
|
|
|
}
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(options->file, "%s", line_prefix);
|
2009-04-25 06:06:47 +08:00
|
|
|
show_name(options->file, prefix, name, len);
|
2012-05-01 04:38:58 +08:00
|
|
|
fprintf(options->file, " %*"PRIuMAX"%s",
|
|
|
|
number_width, added + deleted,
|
|
|
|
added + deleted ? " " : "");
|
2008-03-10 10:43:39 +08:00
|
|
|
show_graph(options->file, '+', add, add_c, reset);
|
|
|
|
show_graph(options->file, '-', del, del_c, reset);
|
|
|
|
fprintf(options->file, "\n");
|
|
|
|
}
|
2011-05-27 20:36:41 +08:00
|
|
|
for (i = count; i < data->nr; i++) {
|
|
|
|
uintmax_t added = data->files[i]->added;
|
|
|
|
uintmax_t deleted = data->files[i]->deleted;
|
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
|
|
|
if (!data->files[i]->is_interesting &&
|
2011-05-27 20:36:41 +08:00
|
|
|
(added + deleted == 0)) {
|
|
|
|
total_files--;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
adds += added;
|
|
|
|
dels += deleted;
|
2011-05-28 12:50:39 +08:00
|
|
|
if (!extra_shown)
|
|
|
|
fprintf(options->file, "%s ...\n", line_prefix);
|
|
|
|
extra_shown = 1;
|
2011-05-27 20:36:41 +08:00
|
|
|
}
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(options->file, "%s", line_prefix);
|
2012-02-01 20:55:07 +08:00
|
|
|
print_stat_summary(options->file, total_files, adds, dels);
|
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;
|
|
|
|
int deleted= data->files[i]->deleted;
|
|
|
|
|
|
|
|
if (data->files[i]->is_unmerged)
|
|
|
|
continue;
|
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
|
|
|
if (!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
|
|
|
}
|
|
|
|
}
|
2010-05-26 15:23:54 +08:00
|
|
|
if (options->output_prefix) {
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
msg = options->output_prefix(options,
|
|
|
|
options->output_prefix_data);
|
|
|
|
fprintf(options->file, "%s", msg->buf);
|
|
|
|
}
|
2012-02-01 20:55:07 +08:00
|
|
|
print_stat_summary(options->file, 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];
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
if (options->output_prefix) {
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
msg = options->output_prefix(options,
|
|
|
|
options->output_prefix_data);
|
|
|
|
fprintf(options->file, "%s", msg->buf);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
|
|
|
unsigned long this_dir = 0;
|
|
|
|
unsigned int sources = 0;
|
2010-05-26 15:23:54 +08:00
|
|
|
const char *line_prefix = "";
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
|
|
|
|
if (opt->output_prefix) {
|
|
|
|
msg = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
line_prefix = msg->buf;
|
|
|
|
}
|
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);
|
|
|
|
unsigned long this;
|
|
|
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
this = 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 {
|
2008-02-13 09:06:58 +08:00
|
|
|
this = 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;
|
|
|
|
}
|
|
|
|
this_dir += this;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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) {
|
Make --dirstat=0 output directories that contribute < 0.1% of changes
The expected output from --dirstat=0, is to include any directory with
changes, even if those changes contribute a minuscule portion of the total
changes. However, currently, directories that contribute less than 0.1% are
not included, since their 'permille' value is 0, and there is an
'if (permille)' check in gather_dirstat() that causes them to be ignored.
This test is obviously intended to exclude directories that contribute no
changes whatsoever, but in this case, it hits too broadly. The correct
check is against 'this_dir' from which the permille is calculated. Only if
this value is 0 does the directory truly contribute no changes, and should
be skipped from the output.
This patches fixes this issue, and updates corresponding testcases to
expect the new behvaior.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29 17:36:17 +08:00
|
|
|
if (this_dir) {
|
|
|
|
int permille = this_dir * 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return this_dir;
|
|
|
|
}
|
|
|
|
|
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;
|
2008-09-03 08:28:59 +08:00
|
|
|
dir.cumulative = DIFF_OPT_TST(options, 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;
|
2011-04-11 06:48:51 +08:00
|
|
|
int content_changed;
|
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
|
|
|
|
2011-04-11 06:48:51 +08:00
|
|
|
if (p->one->sha1_valid && p->two->sha1_valid)
|
|
|
|
content_changed = hashcmp(p->one->sha1, p->two->sha1);
|
|
|
|
else
|
|
|
|
content_changed = 1;
|
|
|
|
|
2011-04-11 06:48:52 +08:00
|
|
|
if (!content_changed) {
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
2011-04-11 06:48:51 +08:00
|
|
|
if (DIFF_OPT_TST(options, DIRSTAT_BY_FILE)) {
|
|
|
|
/*
|
|
|
|
* 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)) {
|
|
|
|
diff_populate_filespec(p->one, 0);
|
|
|
|
diff_populate_filespec(p->two, 0);
|
|
|
|
diffcore_count_changes(p->one, p->two, NULL, NULL, 0,
|
|
|
|
&copied, &added);
|
|
|
|
diff_free_filespec_data(p->one);
|
|
|
|
diff_free_filespec_data(p->two);
|
|
|
|
} else if (DIFF_FILE_VALID(p->one)) {
|
|
|
|
diff_populate_filespec(p->one, 1);
|
|
|
|
copied = added = 0;
|
|
|
|
diff_free_filespec_data(p->one);
|
|
|
|
} else if (DIFF_FILE_VALID(p->two)) {
|
|
|
|
diff_populate_filespec(p->two, 1);
|
|
|
|
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
|
|
|
|
* be identical, but since content_changed is true, we
|
|
|
|
* 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 */
|
2008-08-29 07:19:08 +08:00
|
|
|
qsort(dir.files, dir.nr, sizeof(dir.files[0]), 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;
|
|
|
|
dir.cumulative = DIFF_OPT_TST(options, DIRSTAT_CUMULATIVE);
|
|
|
|
|
|
|
|
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...
|
|
|
|
*/
|
|
|
|
damage = (damage + 63) / 64;
|
|
|
|
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 */
|
|
|
|
qsort(dir.files, dir.nr, sizeof(dir.files[0]), dirstat_compare);
|
|
|
|
gather_dirstat(options, &dir, changed, "", 0);
|
|
|
|
}
|
|
|
|
|
2007-12-12 15:46:30 +08:00
|
|
|
static void free_diffstat_info(struct diffstat_t *diffstat)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < diffstat->nr; i++) {
|
|
|
|
struct diffstat_file *f = diffstat->files[i];
|
|
|
|
if (f->name != f->print_name)
|
|
|
|
free(f->print_name);
|
|
|
|
free(f->name);
|
|
|
|
free(f->from_name);
|
|
|
|
free(f);
|
|
|
|
}
|
|
|
|
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;
|
2010-03-25 10:21:32 +08:00
|
|
|
/* line[1] thru line[marker_size-1] are same as firstchar */
|
|
|
|
if (len < marker_size + 1 || !isspace(line[marker_size]))
|
2008-06-27 06:37:21 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-05-21 05:43:13 +08:00
|
|
|
static void checkdiff_consume(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
char *line_prefix = "";
|
|
|
|
struct strbuf *msgbuf;
|
|
|
|
|
|
|
|
assert(data->o);
|
|
|
|
if (data->o->output_prefix) {
|
|
|
|
msgbuf = data->o->output_prefix(data->o,
|
|
|
|
data->o->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
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)
|
2007-12-13 21:32:29 +08:00
|
|
|
return;
|
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++;
|
2008-06-27 06:36:59 +08:00
|
|
|
} else if (line[0] == '@') {
|
2006-05-21 05:43:13 +08:00
|
|
|
char *plus = strchr(line, '+');
|
|
|
|
if (plus)
|
2008-02-16 12:30:05 +08:00
|
|
|
data->lineno = strtol(plus, NULL, 10) - 1;
|
2006-05-21 05:43:13 +08:00
|
|
|
else
|
|
|
|
die("invalid diff");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
memset(&stream, 0, sizeof(stream));
|
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
|
|
|
}
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static void emit_binary_diff_body(FILE *file, mmfile_t *one, mmfile_t *two, char *prefix)
|
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) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%sdelta %lu\n", prefix, orig_size);
|
2006-05-05 17:41:53 +08:00
|
|
|
free(deflated);
|
|
|
|
data = delta;
|
|
|
|
data_size = delta_size;
|
|
|
|
}
|
|
|
|
else {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%sliteral %lu\n", prefix, two->size);
|
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) {
|
|
|
|
int bytes = (52 < data_size) ? 52 : 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
|
|
|
char line[70];
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%s", prefix);
|
2008-03-10 10:43:39 +08:00
|
|
|
fputs(line, file);
|
|
|
|
fputc('\n', file);
|
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
|
|
|
}
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%s\n", prefix);
|
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
|
|
|
}
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static void emit_binary_diff(FILE *file, mmfile_t *one, mmfile_t *two, char *prefix)
|
2006-08-17 07:08:14 +08:00
|
|
|
{
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%sGIT binary patch\n", prefix);
|
|
|
|
emit_binary_diff_body(file, one, two, prefix);
|
|
|
|
emit_binary_diff_body(file, two, one, prefix);
|
2006-08-17 07:08:14 +08:00
|
|
|
}
|
|
|
|
|
2007-07-06 15:18:54 +08:00
|
|
|
int diff_filespec_is_binary(struct diff_filespec *one)
|
|
|
|
{
|
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) {
|
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
if (one->driver->binary != -1)
|
|
|
|
one->is_binary = one->driver->binary;
|
|
|
|
else {
|
|
|
|
if (!one->data && DIFF_FILE_VALID(one))
|
|
|
|
diff_populate_filespec(one, 0);
|
|
|
|
if (one->data)
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2008-10-06 05:43:21 +08:00
|
|
|
static const struct userdiff_funcname *diff_funcname_pattern(struct diff_filespec *one)
|
2007-07-06 15:45:10 +08:00
|
|
|
{
|
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
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2010-06-07 23:23:36 +08:00
|
|
|
struct userdiff_driver *get_textconv(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
|
|
|
|
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
|
|
|
diff_filespec_load_driver(one);
|
2011-05-24 04:30:14 +08:00
|
|
|
return userdiff_get_textconv(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
|
|
|
}
|
|
|
|
|
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;
|
2010-05-26 15:23:54 +08:00
|
|
|
struct strbuf *msgbuf;
|
|
|
|
char *line_prefix = "";
|
|
|
|
|
|
|
|
if (o->output_prefix) {
|
|
|
|
msgbuf = o->output_prefix(o, o->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
2008-08-19 11:08:09 +08:00
|
|
|
|
2009-10-19 20:38:32 +08:00
|
|
|
if (DIFF_OPT_TST(o, SUBMODULE_LOG) &&
|
|
|
|
(!one->mode || S_ISGITLINK(one->mode)) &&
|
|
|
|
(!two->mode || S_ISGITLINK(two->mode))) {
|
|
|
|
const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
|
|
|
|
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
|
|
|
|
show_submodule_summary(o->file, one ? one->path : two->path,
|
2010-01-24 22:09:00 +08:00
|
|
|
one->sha1, two->sha1, two->dirty_submodule,
|
2012-11-13 23:42:47 +08:00
|
|
|
meta, del, add, reset);
|
2009-10-19 20:38:32 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-12-09 16:13:21 +08:00
|
|
|
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
|
|
|
|
textconv_one = get_textconv(one);
|
|
|
|
textconv_two = get_textconv(two);
|
|
|
|
}
|
|
|
|
|
2008-08-19 11:08:09 +08:00
|
|
|
diff_set_mnemonic_prefix(o, "a/", "b/");
|
|
|
|
if (DIFF_OPT_TST(o, REVERSE_DIFF)) {
|
|
|
|
a_prefix = o->b_prefix;
|
|
|
|
b_prefix = o->a_prefix;
|
|
|
|
} else {
|
|
|
|
a_prefix = o->a_prefix;
|
|
|
|
b_prefix = o->b_prefix;
|
|
|
|
}
|
2006-04-22 14:57:45 +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";
|
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 &&
|
2008-12-09 16:13:21 +08:00
|
|
|
(textconv_one || !diff_filespec_is_binary(one)) &&
|
|
|
|
(textconv_two || !diff_filespec_is_binary(two))) {
|
2009-11-20 05:12:24 +08:00
|
|
|
fprintf(o->file, "%s", header.buf);
|
|
|
|
strbuf_reset(&header);
|
2008-12-09 16:13:21 +08:00
|
|
|
emit_rewrite_diff(name_a, name_b, one, two,
|
|
|
|
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] == '/') {
|
|
|
|
fprintf(o->file, "%s", header.buf);
|
|
|
|
strbuf_reset(&header);
|
|
|
|
goto free_ab_and_return;
|
|
|
|
} else if (!DIFF_OPT_TST(o, TEXT) &&
|
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
|
|
|
( (!textconv_one && diff_filespec_is_binary(one)) ||
|
|
|
|
(!textconv_two && diff_filespec_is_binary(two)) )) {
|
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
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)
|
|
|
|
fprintf(o->file, "%s", header.buf);
|
2006-05-05 17:41:53 +08:00
|
|
|
goto free_ab_and_return;
|
2010-05-26 10:50:12 +08:00
|
|
|
}
|
2009-11-20 05:12:24 +08:00
|
|
|
fprintf(o->file, "%s", header.buf);
|
|
|
|
strbuf_reset(&header);
|
2007-11-11 03:05:14 +08:00
|
|
|
if (DIFF_OPT_TST(o, BINARY))
|
2010-05-26 15:23:54 +08:00
|
|
|
emit_binary_diff(o->file, &mf1, &mf2, line_prefix);
|
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
|
|
|
else
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(o->file, "%sBinary files %s and %s differ\n",
|
|
|
|
line_prefix, lbl[0], lbl[1]);
|
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.. */
|
|
|
|
const char *diffopts = getenv("GIT_DIFF_OPTS");
|
|
|
|
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) {
|
2009-11-20 05:12:24 +08:00
|
|
|
fprintf(o->file, "%s", header.buf);
|
|
|
|
strbuf_reset(&header);
|
|
|
|
}
|
|
|
|
|
2010-04-02 08:09:26 +08:00
|
|
|
mf1.size = fill_textconv(textconv_one, one, &mf1.ptr);
|
|
|
|
mf2.size = fill_textconv(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
|
|
|
|
2008-09-19 06:40:48 +08:00
|
|
|
pe = diff_funcname_pattern(one);
|
|
|
|
if (!pe)
|
|
|
|
pe = diff_funcname_pattern(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));
|
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);
|
2007-02-26 06:34:54 +08:00
|
|
|
ecbdata.found_changesp = &o->found_changes;
|
2007-12-06 16:14:14 +08:00
|
|
|
ecbdata.ws_rule = whitespace_rule(name_b ? name_b : name_a);
|
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;
|
2009-11-20 05:12:24 +08:00
|
|
|
ecbdata.header = header.len ? &header : NULL;
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = o->xdl_opts;
|
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;
|
2011-10-09 19:36:57 +08:00
|
|
|
if (DIFF_OPT_TST(o, FUNCCONTEXT))
|
|
|
|
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);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!diffopts)
|
|
|
|
;
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 17:53:29 +08:00
|
|
|
else if (!prefixcmp(diffopts, "--unified="))
|
2006-04-22 14:57:45 +08:00
|
|
|
xecfg.ctxlen = strtoul(diffopts + 10, NULL, 10);
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 17:53:29 +08:00
|
|
|
else if (!prefixcmp(diffopts, "-u"))
|
2006-04-22 14:57:45 +08:00
|
|
|
xecfg.ctxlen = strtoul(diffopts + 2, NULL, 10);
|
2012-03-15 02:24:08 +08:00
|
|
|
if (o->word_diff)
|
|
|
|
init_diff_words_data(&ecbdata, o, one, two);
|
2008-08-14 14:18:22 +08:00
|
|
|
xdi_diff_outf(&mf1, &mf2, fn_out_consume, &ecbdata,
|
2010-05-05 04:41:34 +08:00
|
|
|
&xpp, &xecfg);
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
2012-05-02 01:10:15 +08:00
|
|
|
int same_contents;
|
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);
|
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
|
|
|
data->is_interesting = p->status != 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (!one || !two) {
|
|
|
|
data->is_unmerged = 1;
|
|
|
|
return;
|
|
|
|
}
|
2011-02-19 16:04:56 +08:00
|
|
|
|
2012-05-02 01:10:15 +08:00
|
|
|
same_contents = !hashcmp(one->sha1, two->sha1);
|
|
|
|
|
2011-02-19 16:04:56 +08:00
|
|
|
if (diff_filespec_is_binary(one) || diff_filespec_is_binary(two)) {
|
|
|
|
data->is_binary = 1;
|
2012-05-02 01:10:15 +08:00
|
|
|
if (same_contents) {
|
2012-05-02 01:10:14 +08:00
|
|
|
data->added = 0;
|
|
|
|
data->deleted = 0;
|
|
|
|
} else {
|
|
|
|
data->added = diff_filespec_size(two);
|
|
|
|
data->deleted = diff_filespec_size(one);
|
|
|
|
}
|
2011-02-19 16:04:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
else if (complete_rewrite) {
|
2006-04-26 14:40:09 +08:00
|
|
|
diff_populate_filespec(one, 0);
|
|
|
|
diff_populate_filespec(two, 0);
|
|
|
|
data->deleted = count_lines(one->data, one->size);
|
|
|
|
data->added = count_lines(two->data, two->size);
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2012-05-02 01:10:15 +08:00
|
|
|
else if (!same_contents) {
|
2006-04-22 14:57:45 +08:00
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
|
2011-02-19 16:04:56 +08:00
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
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;
|
2011-09-23 01:54:47 +08:00
|
|
|
xecfg.ctxlen = o->context;
|
|
|
|
xecfg.interhunkctxlen = o->interhunkcontext;
|
2008-08-14 14:18:22 +08:00
|
|
|
xdi_diff_outf(&mf1, &mf2, diffstat_consume, diffstat,
|
2010-05-05 04:41:34 +08:00
|
|
|
&xpp, &xecfg);
|
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;
|
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
|
|
|
data.ws_rule = whitespace_rule(attr_path);
|
2010-03-25 10:21:32 +08:00
|
|
|
data.conflict_marker_size = ll_merge_marker_size(attr_path);
|
2006-05-21 05:43:13 +08:00
|
|
|
|
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
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.
|
|
|
|
*/
|
2007-07-06 15:18:54 +08:00
|
|
|
if (diff_filespec_is_binary(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;
|
2008-08-14 14:18:22 +08:00
|
|
|
xdi_diff_outf(&mf1, &mf2, checkdiff_consume, &data,
|
2010-05-05 04:41:34 +08:00
|
|
|
&xpp, &xecfg);
|
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)
|
|
|
|
DIFF_OPT_SET(o, CHECK_FAILED);
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
struct diff_filespec *alloc_filespec(const char *path)
|
|
|
|
{
|
|
|
|
int namelen = strlen(path);
|
|
|
|
struct diff_filespec *spec = xmalloc(sizeof(*spec) + namelen + 1);
|
|
|
|
|
|
|
|
memset(spec, 0, sizeof(*spec));
|
|
|
|
spec->path = (char *)(spec + 1);
|
|
|
|
memcpy(spec->path, path, namelen+1);
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void fill_filespec(struct diff_filespec *spec, const unsigned char *sha1,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
int sha1_valid, unsigned short mode)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
if (mode) {
|
|
|
|
spec->mode = canon_mode(mode);
|
2006-08-23 14:49:00 +08:00
|
|
|
hashcpy(spec->sha1, sha1);
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
spec->sha1_valid = sha1_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.
|
|
|
|
*/
|
2006-12-14 19:15:57 +08:00
|
|
|
static int reuse_worktree_file(const char *name, const unsigned char *sha1, int want_file)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
struct cache_entry *ce;
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
if (!active_cache)
|
|
|
|
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.
|
|
|
|
*/
|
2009-02-28 15:15:53 +08:00
|
|
|
if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1))
|
2006-12-14 19:15:57 +08:00
|
|
|
return 0;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
len = strlen(name);
|
|
|
|
pos = cache_name_pos(name, len);
|
|
|
|
if (pos < 0)
|
|
|
|
return 0;
|
|
|
|
ce = active_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.
|
|
|
|
*/
|
|
|
|
if (hashcmp(sha1, ce->sha1) || !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) ||
|
|
|
|
(!lstat(name, &st) && !ce_match_stat(ce, &st, 0)))
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
int len;
|
2010-01-17 01:42:53 +08:00
|
|
|
char *data = xmalloc(100), *dirty = "";
|
|
|
|
|
|
|
|
/* 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";
|
|
|
|
|
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
|
|
|
len = snprintf(data, 100,
|
2010-01-17 01:42:53 +08:00
|
|
|
"Subproject commit %s%s\n", sha1_to_hex(s->sha1), dirty);
|
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
|
|
|
s->data = data;
|
|
|
|
s->size = len;
|
|
|
|
s->should_free = 1;
|
|
|
|
if (size_only) {
|
|
|
|
s->data = NULL;
|
|
|
|
free(data);
|
|
|
|
}
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
int diff_populate_filespec(struct diff_filespec *s, int size_only)
|
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
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);
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (!s->sha1_valid ||
|
2006-12-14 19:15:57 +08:00
|
|
|
reuse_worktree_file(s->path, s->sha1, 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) {
|
|
|
|
if (errno == ENOENT) {
|
|
|
|
err_empty:
|
|
|
|
err = -1;
|
|
|
|
empty:
|
2006-06-25 01:20:32 +08:00
|
|
|
s->data = (char *)"";
|
2006-04-22 14:57:45 +08:00
|
|
|
s->size = 0;
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
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;
|
|
|
|
}
|
2008-12-18 02:26:13 +08:00
|
|
|
if (size_only)
|
|
|
|
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
|
|
|
|
*/
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
appropriately.
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
This patch adds a mechanism that can either warn the user about
an irreversible conversion or can even refuse to convert. The
mechanism is controlled by the variable core.safecrlf, with the
following values:
- false: disable safecrlf mechanism
- warn: warn about irreversible conversions
- true: refuse irreversible conversions
The default is to warn. Users are only affected by this default
if core.autocrlf is set. But the current default of git is to
leave core.autocrlf unset, so users will not see warnings unless
they deliberately chose to activate the autocrlf mechanism.
The safecrlf mechanism's details depend on the git command. The
general principles when safecrlf is active (not false) are:
- we warn/error out if files in the work tree can modified in an
irreversible way without giving the user a chance to backup the
original file.
- for read-only operations that do not modify files in the work tree
we do not not print annoying warnings.
There are exceptions. Even though...
- "git add" itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
- "git apply" to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
- "git diff" itself does not touch the files in the work tree, it is
often run to inspect the changes you intend to next "git add". To
catch potential problems early, safety triggers.
The concept of a safety check was originally proposed in a similar
way by Linus Torvalds. Thanks to Dimitry Potapov for insisting
on getting the naked LF/autocrlf=true case right.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
2008-02-06 19:25:58 +08:00
|
|
|
if (convert_to_git(s->path, s->data, s->size, &buf, safe_crlf)) {
|
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 {
|
2007-02-27 03:55:59 +08:00
|
|
|
enum object_type type;
|
2010-10-22 12:02:27 +08:00
|
|
|
if (size_only) {
|
2007-02-27 03:55:59 +08:00
|
|
|
type = sha1_object_info(s->sha1, &s->size);
|
2010-10-22 12:02:27 +08:00
|
|
|
if (type < 0)
|
|
|
|
die("unable to read %s", sha1_to_hex(s->sha1));
|
|
|
|
} else {
|
2007-02-27 03:55:59 +08:00
|
|
|
s->data = read_sha1_file(s->sha1, &type, &s->size);
|
2010-10-22 12:02:27 +08:00
|
|
|
if (!s->data)
|
|
|
|
die("unable to read %s", sha1_to_hex(s->sha1));
|
2006-04-22 14:57:45 +08:00
|
|
|
s->should_free = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
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)
|
|
|
|
{
|
2007-10-03 12:01:03 +08:00
|
|
|
diff_free_filespec_blob(s);
|
2006-04-22 14:57:45 +08:00
|
|
|
free(s->cnt_data);
|
|
|
|
s->cnt_data = NULL;
|
|
|
|
}
|
|
|
|
|
2009-03-21 19:42:52 +08:00
|
|
|
static void prep_temp_blob(const char *path, struct diff_tempfile *temp,
|
2006-04-22 14:57:45 +08:00
|
|
|
void *blob,
|
|
|
|
unsigned long size,
|
|
|
|
const unsigned char *sha1,
|
|
|
|
int mode)
|
|
|
|
{
|
|
|
|
int fd;
|
2009-03-21 19:42:52 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2009-05-31 16:35:52 +08:00
|
|
|
struct strbuf template = STRBUF_INIT;
|
|
|
|
char *path_dup = xstrdup(path);
|
|
|
|
const char *base = basename(path_dup);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2009-05-31 16:35:52 +08:00
|
|
|
/* Generate "XXXXXX_basename.ext" */
|
|
|
|
strbuf_addstr(&template, "XXXXXX_");
|
|
|
|
strbuf_addstr(&template, base);
|
|
|
|
|
|
|
|
fd = git_mkstemps(temp->tmp_path, PATH_MAX, template.buf,
|
|
|
|
strlen(base) + 1);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (fd < 0)
|
2009-06-27 23:58:46 +08:00
|
|
|
die_errno("unable to create temp-file");
|
2009-03-21 19:42:52 +08:00
|
|
|
if (convert_to_working_tree(path,
|
|
|
|
(const char *)blob, (size_t)size, &buf)) {
|
|
|
|
blob = buf.buf;
|
|
|
|
size = buf.len;
|
|
|
|
}
|
2007-01-08 23:58:23 +08:00
|
|
|
if (write_in_full(fd, blob, size) != size)
|
2009-06-27 23:58:47 +08:00
|
|
|
die_errno("unable to write temp-file");
|
2006-04-22 14:57:45 +08:00
|
|
|
close(fd);
|
|
|
|
temp->name = temp->tmp_path;
|
|
|
|
strcpy(temp->hex, sha1_to_hex(sha1));
|
|
|
|
temp->hex[40] = 0;
|
|
|
|
sprintf(temp->mode, "%06o", mode);
|
2009-03-21 19:42:52 +08:00
|
|
|
strbuf_release(&buf);
|
2009-05-31 16:35:52 +08:00
|
|
|
strbuf_release(&template);
|
|
|
|
free(path_dup);
|
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
|
|
|
static struct diff_tempfile *prepare_temp_file(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";
|
|
|
|
strcpy(temp->hex, ".");
|
|
|
|
strcpy(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;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!remove_tempfile_installed) {
|
|
|
|
atexit(remove_tempfile);
|
2009-01-22 14:03:08 +08:00
|
|
|
sigchain_push_common(remove_tempfile_on_signal);
|
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_installed = 1;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!one->sha1_valid ||
|
2006-12-14 19:15:57 +08:00
|
|
|
reuse_worktree_file(name, one->sha1, 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);
|
2009-05-25 18:46:09 +08:00
|
|
|
prep_temp_blob(name, temp, sb.buf, sb.len,
|
2006-04-22 14:57:45 +08:00
|
|
|
(one->sha1_valid ?
|
|
|
|
one->sha1 : null_sha1),
|
|
|
|
(one->sha1_valid ?
|
|
|
|
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;
|
|
|
|
if (!one->sha1_valid)
|
|
|
|
strcpy(temp->hex, sha1_to_hex(null_sha1));
|
|
|
|
else
|
|
|
|
strcpy(temp->hex, sha1_to_hex(one->sha1));
|
|
|
|
/* Even though we may sometimes borrow the
|
|
|
|
* contents from the work tree, we always want
|
|
|
|
* one->mode. mode is trustworthy even when
|
|
|
|
* !(one->sha1_valid), as long as
|
|
|
|
* DIFF_FILE_VALID(one).
|
|
|
|
*/
|
|
|
|
sprintf(temp->mode, "%06o", one->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;
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (diff_populate_filespec(one, 0))
|
|
|
|
die("cannot read data blob for %s", one->path);
|
2009-03-21 19:42:52 +08:00
|
|
|
prep_temp_blob(name, temp, one->data, one->size,
|
2006-04-22 14:57:45 +08:00
|
|
|
one->sha1, one->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;
|
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,
|
|
|
|
int complete_rewrite)
|
|
|
|
{
|
|
|
|
const char *spawn_arg[10];
|
|
|
|
int retval;
|
|
|
|
const char **arg = &spawn_arg[0];
|
|
|
|
|
|
|
|
if (one && two) {
|
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_one, *temp_two;
|
|
|
|
const char *othername = (other ? other : name);
|
|
|
|
temp_one = prepare_temp_file(name, one);
|
|
|
|
temp_two = prepare_temp_file(othername, two);
|
2006-04-22 14:57:45 +08:00
|
|
|
*arg++ = pgm;
|
|
|
|
*arg++ = name;
|
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
|
|
|
*arg++ = temp_one->name;
|
|
|
|
*arg++ = temp_one->hex;
|
|
|
|
*arg++ = temp_one->mode;
|
|
|
|
*arg++ = temp_two->name;
|
|
|
|
*arg++ = temp_two->hex;
|
|
|
|
*arg++ = temp_two->mode;
|
2006-04-22 14:57:45 +08:00
|
|
|
if (other) {
|
|
|
|
*arg++ = other;
|
|
|
|
*arg++ = xfrm_msg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
*arg++ = pgm;
|
|
|
|
*arg++ = name;
|
|
|
|
}
|
|
|
|
*arg = NULL;
|
2007-10-20 03:47:56 +08:00
|
|
|
fflush(NULL);
|
2009-12-30 19:03:35 +08:00
|
|
|
retval = run_command_v_opt(spawn_arg, RUN_USING_SHELL);
|
2006-04-22 14:57:45 +08:00
|
|
|
remove_tempfile();
|
|
|
|
if (retval) {
|
|
|
|
fprintf(stderr, "external diff died, stopping at %s.\n", name);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-26 16:08:24 +08:00
|
|
|
static int similarity_index(struct diff_filepair *p)
|
|
|
|
{
|
|
|
|
return p->score * 100 / MAX_SCORE;
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
2010-05-26 15:23:54 +08:00
|
|
|
struct strbuf *msgbuf;
|
|
|
|
char *line_prefix = "";
|
|
|
|
|
2010-05-26 10:50:12 +08:00
|
|
|
*must_show_header = 1;
|
2010-05-26 15:23:54 +08:00
|
|
|
if (o->output_prefix) {
|
|
|
|
msgbuf = o->output_prefix(o, o->output_prefix_data);
|
|
|
|
line_prefix = msgbuf->buf;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
if (one && two && hashcmp(one->sha1, two->sha1)) {
|
|
|
|
int abbrev = DIFF_OPT_TST(o, FULL_INDEX) ? 40 : DEFAULT_ABBREV;
|
|
|
|
|
|
|
|
if (DIFF_OPT_TST(o, BINARY)) {
|
|
|
|
mmfile_t mf;
|
|
|
|
if ((!fill_mmfile(&mf, one) && diff_filespec_is_binary(one)) ||
|
|
|
|
(!fill_mmfile(&mf, two) && diff_filespec_is_binary(two)))
|
|
|
|
abbrev = 40;
|
|
|
|
}
|
2010-07-08 23:12:34 +08:00
|
|
|
strbuf_addf(msg, "%s%sindex %s..", line_prefix, set,
|
2010-05-30 21:37:17 +08:00
|
|
|
find_unique_abbrev(one->sha1, abbrev));
|
|
|
|
strbuf_addstr(msg, find_unique_abbrev(two->sha1, 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
|
|
|
|
|
|
|
if (DIFF_OPT_TST(o, ALLOW_EXTERNAL)) {
|
2008-10-06 05:43:21 +08:00
|
|
|
struct userdiff_driver *drv = userdiff_find_by_path(attr_path);
|
|
|
|
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) {
|
|
|
|
run_external_diff(pgm, name, other, one, two, xfrm_msg,
|
|
|
|
complete_rewrite);
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
static void diff_fill_sha1_info(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (DIFF_FILE_VALID(one)) {
|
|
|
|
if (!one->sha1_valid) {
|
|
|
|
struct stat st;
|
2012-06-28 11:14:47 +08:00
|
|
|
if (one->is_stdin) {
|
2007-02-26 06:36:10 +08:00
|
|
|
hashcpy(one->sha1, null_sha1);
|
|
|
|
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);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (index_path(one->sha1, 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
|
2006-08-23 14:49:00 +08:00
|
|
|
hashclr(one->sha1);
|
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 */
|
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 != '/') {
|
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;
|
|
|
|
}
|
|
|
|
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
|
|
|
*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
|
|
|
|
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
|
|
|
name = p->one->path;
|
|
|
|
other = (strcmp(name, p->two->path) ? p->two->path : NULL);
|
|
|
|
attr_path = name;
|
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2012-07-18 13:08:59 +08:00
|
|
|
if (!DIFF_OPT_TST(o, ALLOW_EXTERNAL))
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
diff_fill_sha1_info(one);
|
|
|
|
diff_fill_sha1_info(two);
|
|
|
|
|
|
|
|
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,
|
2009-01-26 16:08:24 +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 */
|
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
|
|
|
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);
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
diff_fill_sha1_info(p->one);
|
|
|
|
diff_fill_sha1_info(p->two);
|
|
|
|
|
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
|
|
|
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
|
|
|
|
|
|
|
diff_fill_sha1_info(p->one);
|
|
|
|
diff_fill_sha1_info(p->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
|
|
|
builtin_checkdiff(name, other, attr_path, p->one, p->two, o);
|
2006-05-21 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void diff_setup(struct diff_options *options)
|
|
|
|
{
|
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;
|
|
|
|
|
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;
|
teach diffcore-rename to optionally ignore empty content
Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.
However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).
This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.
One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).
A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-23 06:52:13 +08:00
|
|
|
DIFF_OPT_SET(options, RENAME_EMPTY);
|
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;
|
2007-12-19 03:32:14 +08:00
|
|
|
|
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/";
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2012-08-03 20:16:24 +08:00
|
|
|
void diff_setup_done(struct diff_options *options)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
2006-06-25 01:26:49 +08:00
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
if (options->output_format & DIFF_FORMAT_NAME)
|
|
|
|
count++;
|
|
|
|
if (options->output_format & DIFF_FORMAT_NAME_STATUS)
|
|
|
|
count++;
|
|
|
|
if (options->output_format & DIFF_FORMAT_CHECKDIFF)
|
|
|
|
count++;
|
|
|
|
if (options->output_format & DIFF_FORMAT_NO_OUTPUT)
|
|
|
|
count++;
|
|
|
|
if (count > 1)
|
|
|
|
die("--name-only, --name-status, --check and -s are mutually exclusive");
|
|
|
|
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
|
|
|
|
DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
|
|
|
|
DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL))
|
|
|
|
DIFF_OPT_SET(options, DIFF_FROM_CONTENTS);
|
|
|
|
else
|
|
|
|
DIFF_OPT_CLR(options, DIFF_FROM_CONTENTS);
|
|
|
|
|
2007-11-11 03:05:14 +08:00
|
|
|
if (DIFF_OPT_TST(options, FIND_COPIES_HARDER))
|
2006-08-10 04:17:19 +08:00
|
|
|
options->detect_rename = DIFF_DETECT_COPY;
|
|
|
|
|
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 (!DIFF_OPT_TST(options, RELATIVE_NAME))
|
|
|
|
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))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, RECURSIVE);
|
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
|
|
|
*/
|
2006-06-28 06:08:19 +08:00
|
|
|
if (options->pickaxe)
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, RECURSIVE);
|
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)
|
|
|
|
DIFF_OPT_SET(options, DIRTY_SUBMODULES);
|
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;
|
|
|
|
if (options->setup & DIFF_SETUP_USE_CACHE) {
|
|
|
|
if (!active_cache)
|
|
|
|
/* read-cache does not die even when it fails
|
|
|
|
* so it is safe for us to do this here. Also
|
|
|
|
* it does not smudge active_cache or active_nr
|
|
|
|
* when it fails, so we do not have to worry about
|
|
|
|
* cleaning it up ourselves either.
|
|
|
|
*/
|
|
|
|
read_cache();
|
|
|
|
}
|
|
|
|
if (options->abbrev <= 0 || 40 < options->abbrev)
|
|
|
|
options->abbrev = 40; /* full */
|
|
|
|
|
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.
|
|
|
|
*/
|
2009-05-23 16:15:35 +08:00
|
|
|
if (DIFF_OPT_TST(options, QUICK)) {
|
2007-03-15 02:12:13 +08:00
|
|
|
options->output_format = DIFF_FORMAT_NO_OUTPUT;
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, EXIT_WITH_STATUS);
|
2007-03-15 02:12:13 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
2006-06-25 01:20:32 +08:00
|
|
|
static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val)
|
2006-05-14 04:23:48 +08:00
|
|
|
{
|
|
|
|
char c, *eq;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if (*arg != '-')
|
|
|
|
return 0;
|
|
|
|
c = *++arg;
|
|
|
|
if (!c)
|
|
|
|
return 0;
|
|
|
|
if (c == arg_short) {
|
|
|
|
c = *++arg;
|
|
|
|
if (!c)
|
|
|
|
return 1;
|
|
|
|
if (val && isdigit(c)) {
|
|
|
|
char *end;
|
|
|
|
int n = strtoul(arg, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return 0;
|
|
|
|
*val = n;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (c != '-')
|
|
|
|
return 0;
|
|
|
|
arg++;
|
|
|
|
eq = strchr(arg, '=');
|
|
|
|
if (eq)
|
|
|
|
len = eq - arg;
|
|
|
|
else
|
|
|
|
len = strlen(arg);
|
|
|
|
if (!len || strncmp(arg, arg_long, len))
|
|
|
|
return 0;
|
|
|
|
if (eq) {
|
|
|
|
int n;
|
|
|
|
char *end;
|
|
|
|
if (!isdigit(*++eq))
|
|
|
|
return 0;
|
|
|
|
n = strtoul(eq, &end, 10);
|
|
|
|
if (*end)
|
|
|
|
return 0;
|
|
|
|
*val = n;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2007-06-08 17:54:57 +08:00
|
|
|
static int diff_scoreopt_parse(const char *opt);
|
|
|
|
|
2010-08-05 16:22:52 +08:00
|
|
|
static inline int short_opt(char opt, const char **argv,
|
|
|
|
const char **optarg)
|
|
|
|
{
|
|
|
|
const char *arg = argv[0];
|
|
|
|
if (arg[0] != '-' || arg[1] != opt)
|
|
|
|
return 0;
|
|
|
|
if (arg[2] != '\0') {
|
|
|
|
*optarg = arg + 2;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (!argv[1])
|
|
|
|
die("Option '%c' requires a value", opt);
|
|
|
|
*optarg = argv[1];
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
int parse_long_opt(const char *opt, const char **argv,
|
|
|
|
const char **optarg)
|
|
|
|
{
|
|
|
|
const char *arg = argv[0];
|
|
|
|
if (arg[0] != '-' || arg[1] != '-')
|
|
|
|
return 0;
|
|
|
|
arg += strlen("--");
|
|
|
|
if (prefixcmp(arg, opt))
|
|
|
|
return 0;
|
|
|
|
arg += strlen(opt);
|
|
|
|
if (*arg == '=') { /* sticked form: --option=value */
|
|
|
|
*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;
|
|
|
|
}
|
|
|
|
|
2010-08-05 16:22:53 +08:00
|
|
|
static int stat_opt(struct diff_options *options, const char **av)
|
|
|
|
{
|
|
|
|
const char *arg = av[0];
|
|
|
|
char *end;
|
|
|
|
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;
|
2010-08-05 16:22:54 +08:00
|
|
|
int argcount = 1;
|
2010-08-05 16:22:53 +08:00
|
|
|
|
|
|
|
arg += strlen("--stat");
|
|
|
|
end = (char *)arg;
|
|
|
|
|
|
|
|
switch (*arg) {
|
|
|
|
case '-':
|
2010-08-05 16:22:54 +08:00
|
|
|
if (!prefixcmp(arg, "-width")) {
|
|
|
|
arg += strlen("-width");
|
|
|
|
if (*arg == '=')
|
|
|
|
width = strtoul(arg + 1, &end, 10);
|
|
|
|
else if (!*arg && !av[1])
|
|
|
|
die("Option '--stat-width' requires a value");
|
|
|
|
else if (!*arg) {
|
|
|
|
width = strtoul(av[1], &end, 10);
|
|
|
|
argcount = 2;
|
|
|
|
}
|
|
|
|
} else if (!prefixcmp(arg, "-name-width")) {
|
|
|
|
arg += strlen("-name-width");
|
|
|
|
if (*arg == '=')
|
|
|
|
name_width = strtoul(arg + 1, &end, 10);
|
|
|
|
else if (!*arg && !av[1])
|
|
|
|
die("Option '--stat-name-width' requires a value");
|
|
|
|
else if (!*arg) {
|
|
|
|
name_width = strtoul(av[1], &end, 10);
|
|
|
|
argcount = 2;
|
|
|
|
}
|
2012-03-01 20:26:45 +08:00
|
|
|
} else if (!prefixcmp(arg, "-graph-width")) {
|
|
|
|
arg += strlen("-graph-width");
|
|
|
|
if (*arg == '=')
|
|
|
|
graph_width = strtoul(arg + 1, &end, 10);
|
|
|
|
else if (!*arg && !av[1])
|
|
|
|
die("Option '--stat-graph-width' requires a value");
|
|
|
|
else if (!*arg) {
|
|
|
|
graph_width = strtoul(av[1], &end, 10);
|
|
|
|
argcount = 2;
|
|
|
|
}
|
2011-05-27 20:36:41 +08:00
|
|
|
} else if (!prefixcmp(arg, "-count")) {
|
|
|
|
arg += strlen("-count");
|
|
|
|
if (*arg == '=')
|
|
|
|
count = strtoul(arg + 1, &end, 10);
|
|
|
|
else if (!*arg && !av[1])
|
|
|
|
die("Option '--stat-count' requires a value");
|
|
|
|
else if (!*arg) {
|
|
|
|
count = strtoul(av[1], &end, 10);
|
|
|
|
argcount = 2;
|
|
|
|
}
|
2010-08-05 16:22:54 +08:00
|
|
|
}
|
2010-08-05 16:22:53 +08:00
|
|
|
break;
|
|
|
|
case '=':
|
|
|
|
width = strtoul(arg+1, &end, 10);
|
|
|
|
if (*end == ',')
|
|
|
|
name_width = strtoul(end+1, &end, 10);
|
2011-05-27 20:36:41 +08:00
|
|
|
if (*end == ',')
|
|
|
|
count = strtoul(end+1, &end, 10);
|
2010-08-05 16:22:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Important! This checks all the error cases! */
|
|
|
|
if (*end)
|
|
|
|
return 0;
|
|
|
|
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;
|
2010-08-05 16:22:54 +08:00
|
|
|
return argcount;
|
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;
|
|
|
|
}
|
|
|
|
|
2012-11-13 23:42:45 +08:00
|
|
|
static int parse_submodule_opt(struct diff_options *options, const char *value)
|
|
|
|
{
|
|
|
|
if (parse_submodule_params(options, value))
|
|
|
|
die(_("Failed to parse --submodule option parameter: '%s'"),
|
|
|
|
value);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
int diff_opt_parse(struct diff_options *options, const char **av, int ac)
|
|
|
|
{
|
|
|
|
const char *arg = av[0];
|
2010-08-05 16:22:52 +08:00
|
|
|
const char *optarg;
|
|
|
|
int argcount;
|
2007-11-07 18:20:32 +08:00
|
|
|
|
|
|
|
/* Output format options */
|
2010-05-13 16:59:00 +08:00
|
|
|
if (!strcmp(arg, "-p") || !strcmp(arg, "-u") || !strcmp(arg, "--patch"))
|
2006-06-25 01:21:53 +08:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH;
|
2006-05-14 04:23:48 +08:00
|
|
|
else if (opt_arg(arg, 'U', "unified", &options->context))
|
2006-06-25 01:21:53 +08:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH;
|
2006-06-25 01:23:06 +08:00
|
|
|
else if (!strcmp(arg, "--raw"))
|
|
|
|
options->output_format |= DIFF_FORMAT_RAW;
|
2007-11-11 03:05:14 +08:00
|
|
|
else if (!strcmp(arg, "--patch-with-raw"))
|
2006-06-25 01:21:53 +08:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH | DIFF_FORMAT_RAW;
|
2007-11-11 03:05:14 +08:00
|
|
|
else if (!strcmp(arg, "--numstat"))
|
2006-10-12 18:01:00 +08:00
|
|
|
options->output_format |= DIFF_FORMAT_NUMSTAT;
|
2007-11-11 03:05:14 +08:00
|
|
|
else if (!strcmp(arg, "--shortstat"))
|
2006-12-15 12:15:44 +08:00
|
|
|
options->output_format |= DIFF_FORMAT_SHORTSTAT;
|
2011-04-29 17:36:18 +08:00
|
|
|
else if (!strcmp(arg, "-X") || !strcmp(arg, "--dirstat"))
|
|
|
|
return parse_dirstat_opt(options, "");
|
|
|
|
else if (!prefixcmp(arg, "-X"))
|
|
|
|
return parse_dirstat_opt(options, arg + 2);
|
|
|
|
else if (!prefixcmp(arg, "--dirstat="))
|
|
|
|
return parse_dirstat_opt(options, arg + 10);
|
|
|
|
else if (!strcmp(arg, "--cumulative"))
|
|
|
|
return parse_dirstat_opt(options, "cumulative");
|
|
|
|
else if (!strcmp(arg, "--dirstat-by-file"))
|
|
|
|
return parse_dirstat_opt(options, "files");
|
|
|
|
else if (!prefixcmp(arg, "--dirstat-by-file=")) {
|
|
|
|
parse_dirstat_opt(options, "files");
|
|
|
|
return parse_dirstat_opt(options, arg + 18);
|
2008-09-03 08:28:59 +08:00
|
|
|
}
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--check"))
|
|
|
|
options->output_format |= DIFF_FORMAT_CHECKDIFF;
|
|
|
|
else if (!strcmp(arg, "--summary"))
|
|
|
|
options->output_format |= DIFF_FORMAT_SUMMARY;
|
|
|
|
else if (!strcmp(arg, "--patch-with-stat"))
|
|
|
|
options->output_format |= DIFF_FORMAT_PATCH | DIFF_FORMAT_DIFFSTAT;
|
|
|
|
else if (!strcmp(arg, "--name-only"))
|
|
|
|
options->output_format |= DIFF_FORMAT_NAME;
|
|
|
|
else if (!strcmp(arg, "--name-status"))
|
|
|
|
options->output_format |= DIFF_FORMAT_NAME_STATUS;
|
|
|
|
else if (!strcmp(arg, "-s"))
|
|
|
|
options->output_format |= DIFF_FORMAT_NO_OUTPUT;
|
2010-08-05 16:22:53 +08:00
|
|
|
else if (!prefixcmp(arg, "--stat"))
|
2011-05-27 20:36:41 +08:00
|
|
|
/* --stat, --stat-width, --stat-name-width, or --stat-count */
|
2010-08-05 16:22:53 +08:00
|
|
|
return stat_opt(options, av);
|
2007-11-07 18:20:32 +08:00
|
|
|
|
|
|
|
/* renames options */
|
2010-09-28 07:58:26 +08:00
|
|
|
else if (!prefixcmp(arg, "-B") || !prefixcmp(arg, "--break-rewrites=") ||
|
|
|
|
!strcmp(arg, "--break-rewrites")) {
|
2007-11-11 03:05:14 +08:00
|
|
|
if ((options->break_opt = diff_scoreopt_parse(arg)) == -1)
|
2010-10-21 22:49:47 +08:00
|
|
|
return error("invalid argument to -B: %s", arg+2);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
2010-11-11 04:27:12 +08:00
|
|
|
else if (!prefixcmp(arg, "-M") || !prefixcmp(arg, "--find-renames=") ||
|
|
|
|
!strcmp(arg, "--find-renames")) {
|
2007-11-11 03:05:14 +08:00
|
|
|
if ((options->rename_score = diff_scoreopt_parse(arg)) == -1)
|
2010-10-21 22:49:47 +08:00
|
|
|
return error("invalid argument to -M: %s", arg+2);
|
2006-04-22 14:57:45 +08:00
|
|
|
options->detect_rename = DIFF_DETECT_RENAME;
|
|
|
|
}
|
2011-03-01 08:11:55 +08:00
|
|
|
else if (!strcmp(arg, "-D") || !strcmp(arg, "--irreversible-delete")) {
|
|
|
|
options->irreversible_delete = 1;
|
|
|
|
}
|
2010-11-11 04:27:12 +08:00
|
|
|
else if (!prefixcmp(arg, "-C") || !prefixcmp(arg, "--find-copies=") ||
|
|
|
|
!strcmp(arg, "--find-copies")) {
|
2007-06-12 04:12:19 +08:00
|
|
|
if (options->detect_rename == DIFF_DETECT_COPY)
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
|
|
|
|
if ((options->rename_score = diff_scoreopt_parse(arg)) == -1)
|
2010-10-21 22:49:47 +08:00
|
|
|
return error("invalid argument to -C: %s", arg+2);
|
2006-04-22 14:57:45 +08:00
|
|
|
options->detect_rename = DIFF_DETECT_COPY;
|
|
|
|
}
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--no-renames"))
|
|
|
|
options->detect_rename = 0;
|
teach diffcore-rename to optionally ignore empty content
Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.
However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).
This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.
One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).
A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-23 06:52:13 +08:00
|
|
|
else if (!strcmp(arg, "--rename-empty"))
|
|
|
|
DIFF_OPT_SET(options, RENAME_EMPTY);
|
|
|
|
else if (!strcmp(arg, "--no-rename-empty"))
|
|
|
|
DIFF_OPT_CLR(options, RENAME_EMPTY);
|
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 (!strcmp(arg, "--relative"))
|
|
|
|
DIFF_OPT_SET(options, RELATIVE_NAME);
|
2008-02-13 16:34:39 +08:00
|
|
|
else if (!prefixcmp(arg, "--relative=")) {
|
|
|
|
DIFF_OPT_SET(options, RELATIVE_NAME);
|
|
|
|
options->prefix = arg + 11;
|
|
|
|
}
|
2007-11-07 18:20:32 +08:00
|
|
|
|
|
|
|
/* xdiff options */
|
2011-10-02 12:56:28 +08:00
|
|
|
else if (!strcmp(arg, "--minimal"))
|
|
|
|
DIFF_XDL_SET(options, NEED_MINIMAL);
|
|
|
|
else if (!strcmp(arg, "--no-minimal"))
|
|
|
|
DIFF_XDL_CLR(options, NEED_MINIMAL);
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "-w") || !strcmp(arg, "--ignore-all-space"))
|
2009-02-17 11:26:49 +08:00
|
|
|
DIFF_XDL_SET(options, IGNORE_WHITESPACE);
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "-b") || !strcmp(arg, "--ignore-space-change"))
|
2009-02-17 11:26:49 +08:00
|
|
|
DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE);
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--ignore-space-at-eol"))
|
2009-02-17 11:26:49 +08:00
|
|
|
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
|
2009-01-02 00:39:17 +08:00
|
|
|
else if (!strcmp(arg, "--patience"))
|
2012-02-20 07:36:55 +08:00
|
|
|
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
|
2011-07-12 14:10:25 +08:00
|
|
|
else if (!strcmp(arg, "--histogram"))
|
2012-02-20 07:36:55 +08:00
|
|
|
options->xdl_opts = DIFF_WITH_ALG(options, HISTOGRAM_DIFF);
|
2007-11-07 18:20:32 +08:00
|
|
|
|
|
|
|
/* flags options */
|
|
|
|
else if (!strcmp(arg, "--binary")) {
|
|
|
|
options->output_format |= DIFF_FORMAT_PATCH;
|
|
|
|
DIFF_OPT_SET(options, BINARY);
|
|
|
|
}
|
|
|
|
else if (!strcmp(arg, "--full-index"))
|
|
|
|
DIFF_OPT_SET(options, FULL_INDEX);
|
|
|
|
else if (!strcmp(arg, "-a") || !strcmp(arg, "--text"))
|
|
|
|
DIFF_OPT_SET(options, TEXT);
|
|
|
|
else if (!strcmp(arg, "-R"))
|
|
|
|
DIFF_OPT_SET(options, REVERSE_DIFF);
|
2006-04-22 14:57:45 +08:00
|
|
|
else if (!strcmp(arg, "--find-copies-harder"))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
|
Finally implement "git log --follow"
Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.
But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..
The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.
So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.
To make a long story short: I'm sorry for it taking so long until I just
did it.
I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.
All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.
One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.
IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.
Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.
And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do
git log -p --follow builtin-rev-list.c
and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-20 05:22:46 +08:00
|
|
|
else if (!strcmp(arg, "--follow"))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, FOLLOW_RENAMES);
|
2006-06-14 00:45:44 +08:00
|
|
|
else if (!strcmp(arg, "--color"))
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = 1;
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 12:55:58 +08:00
|
|
|
else if (!prefixcmp(arg, "--color=")) {
|
2011-08-18 13:03:48 +08:00
|
|
|
int value = git_config_colorbool(NULL, arg+8);
|
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 (value < 0)
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 12:55:58 +08:00
|
|
|
return error("option `color' expects \"always\", \"auto\", or \"never\"");
|
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
|
|
|
options->use_color = value;
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 12:55:58 +08:00
|
|
|
}
|
2006-07-07 20:27:24 +08:00
|
|
|
else if (!strcmp(arg, "--no-color"))
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = 0;
|
2009-02-17 11:26:49 +08:00
|
|
|
else if (!strcmp(arg, "--color-words")) {
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = 1;
|
2010-04-14 23:59:06 +08:00
|
|
|
options->word_diff = DIFF_WORDS_COLOR;
|
2009-02-17 11:26:49 +08:00
|
|
|
}
|
2009-01-18 00:29:45 +08:00
|
|
|
else if (!prefixcmp(arg, "--color-words=")) {
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = 1;
|
2010-04-14 23:59:06 +08:00
|
|
|
options->word_diff = DIFF_WORDS_COLOR;
|
2009-01-18 00:29:45 +08:00
|
|
|
options->word_regex = arg + 14;
|
|
|
|
}
|
2010-04-14 23:59:06 +08:00
|
|
|
else if (!strcmp(arg, "--word-diff")) {
|
|
|
|
if (options->word_diff == DIFF_WORDS_NONE)
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
|
|
|
}
|
|
|
|
else if (!prefixcmp(arg, "--word-diff=")) {
|
|
|
|
const char *type = arg + 12;
|
|
|
|
if (!strcmp(type, "plain"))
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
|
|
|
else if (!strcmp(type, "color")) {
|
2011-08-18 13:03:12 +08:00
|
|
|
options->use_color = 1;
|
2010-04-14 23:59:06 +08:00
|
|
|
options->word_diff = DIFF_WORDS_COLOR;
|
|
|
|
}
|
|
|
|
else if (!strcmp(type, "porcelain"))
|
|
|
|
options->word_diff = DIFF_WORDS_PORCELAIN;
|
|
|
|
else if (!strcmp(type, "none"))
|
|
|
|
options->word_diff = DIFF_WORDS_NONE;
|
|
|
|
else
|
|
|
|
die("bad --word-diff argument: %s", type);
|
|
|
|
}
|
2010-08-05 16:22:52 +08:00
|
|
|
else if ((argcount = parse_long_opt("word-diff-regex", av, &optarg))) {
|
2010-04-14 23:59:06 +08:00
|
|
|
if (options->word_diff == DIFF_WORDS_NONE)
|
|
|
|
options->word_diff = DIFF_WORDS_PLAIN;
|
2010-08-05 16:22:52 +08:00
|
|
|
options->word_regex = optarg;
|
|
|
|
return argcount;
|
2010-04-14 23:59:06 +08:00
|
|
|
}
|
2007-03-14 08:17:04 +08:00
|
|
|
else if (!strcmp(arg, "--exit-code"))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, EXIT_WITH_STATUS);
|
2007-03-15 02:12:13 +08:00
|
|
|
else if (!strcmp(arg, "--quiet"))
|
2009-05-23 16:15:35 +08:00
|
|
|
DIFF_OPT_SET(options, QUICK);
|
2007-07-01 01:47:07 +08:00
|
|
|
else if (!strcmp(arg, "--ext-diff"))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, ALLOW_EXTERNAL);
|
2007-07-01 01:47:07 +08:00
|
|
|
else if (!strcmp(arg, "--no-ext-diff"))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
|
2008-12-08 10:57:01 +08:00
|
|
|
else if (!strcmp(arg, "--textconv"))
|
|
|
|
DIFF_OPT_SET(options, ALLOW_TEXTCONV);
|
|
|
|
else if (!strcmp(arg, "--no-textconv"))
|
|
|
|
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
|
2010-08-06 06:39:25 +08:00
|
|
|
else if (!strcmp(arg, "--ignore-submodules")) {
|
|
|
|
DIFF_OPT_SET(options, OVERRIDE_SUBMODULE_CONFIG);
|
2010-06-25 22:56:47 +08:00
|
|
|
handle_ignore_submodules_arg(options, "all");
|
2010-08-06 06:39:25 +08:00
|
|
|
} else if (!prefixcmp(arg, "--ignore-submodules=")) {
|
|
|
|
DIFF_OPT_SET(options, OVERRIDE_SUBMODULE_CONFIG);
|
2010-06-25 22:56:47 +08:00
|
|
|
handle_ignore_submodules_arg(options, arg + 20);
|
2010-08-06 06:39:25 +08:00
|
|
|
} else if (!strcmp(arg, "--submodule"))
|
2009-10-19 20:38:32 +08:00
|
|
|
DIFF_OPT_SET(options, SUBMODULE_LOG);
|
2012-11-13 23:42:45 +08:00
|
|
|
else if (!prefixcmp(arg, "--submodule="))
|
|
|
|
return parse_submodule_opt(options, arg + 12);
|
2007-11-07 18:20:32 +08:00
|
|
|
|
|
|
|
/* misc options */
|
|
|
|
else if (!strcmp(arg, "-z"))
|
|
|
|
options->line_termination = 0;
|
2010-08-05 16:22:52 +08:00
|
|
|
else if ((argcount = short_opt('l', av, &optarg))) {
|
|
|
|
options->rename_limit = strtoul(optarg, NULL, 10);
|
|
|
|
return argcount;
|
|
|
|
}
|
|
|
|
else if ((argcount = short_opt('S', av, &optarg))) {
|
|
|
|
options->pickaxe = optarg;
|
2010-08-24 01:17:03 +08:00
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_KIND_S;
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = short_opt('G', av, &optarg))) {
|
|
|
|
options->pickaxe = optarg;
|
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_KIND_G;
|
2010-08-05 16:22:52 +08:00
|
|
|
return argcount;
|
|
|
|
}
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--pickaxe-all"))
|
2010-08-24 01:17:03 +08:00
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_ALL;
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--pickaxe-regex"))
|
2010-08-24 01:17:03 +08:00
|
|
|
options->pickaxe_opts |= DIFF_PICKAXE_REGEX;
|
2010-08-05 16:22:52 +08:00
|
|
|
else if ((argcount = short_opt('O', av, &optarg))) {
|
|
|
|
options->orderfile = optarg;
|
|
|
|
return argcount;
|
|
|
|
}
|
|
|
|
else if ((argcount = parse_long_opt("diff-filter", av, &optarg))) {
|
|
|
|
options->filter = optarg;
|
|
|
|
return argcount;
|
|
|
|
}
|
2007-11-07 18:20:32 +08:00
|
|
|
else if (!strcmp(arg, "--abbrev"))
|
|
|
|
options->abbrev = DEFAULT_ABBREV;
|
|
|
|
else if (!prefixcmp(arg, "--abbrev=")) {
|
|
|
|
options->abbrev = strtoul(arg + 9, NULL, 10);
|
|
|
|
if (options->abbrev < MINIMUM_ABBREV)
|
|
|
|
options->abbrev = MINIMUM_ABBREV;
|
|
|
|
else if (40 < options->abbrev)
|
|
|
|
options->abbrev = 40;
|
|
|
|
}
|
2010-08-05 16:22:52 +08:00
|
|
|
else if ((argcount = parse_long_opt("src-prefix", av, &optarg))) {
|
|
|
|
options->a_prefix = optarg;
|
|
|
|
return argcount;
|
|
|
|
}
|
|
|
|
else if ((argcount = parse_long_opt("dst-prefix", av, &optarg))) {
|
|
|
|
options->b_prefix = optarg;
|
|
|
|
return argcount;
|
|
|
|
}
|
2007-12-19 03:32:14 +08:00
|
|
|
else if (!strcmp(arg, "--no-prefix"))
|
|
|
|
options->a_prefix = options->b_prefix = "";
|
2008-12-29 02:45:32 +08:00
|
|
|
else if (opt_arg(arg, '\0', "inter-hunk-context",
|
|
|
|
&options->interhunkcontext))
|
|
|
|
;
|
2011-10-09 19:36:57 +08:00
|
|
|
else if (!strcmp(arg, "-W"))
|
|
|
|
DIFF_OPT_SET(options, FUNCCONTEXT);
|
|
|
|
else if (!strcmp(arg, "--function-context"))
|
|
|
|
DIFF_OPT_SET(options, FUNCCONTEXT);
|
|
|
|
else if (!strcmp(arg, "--no-function-context"))
|
|
|
|
DIFF_OPT_CLR(options, FUNCCONTEXT);
|
2010-08-05 16:22:52 +08:00
|
|
|
else if ((argcount = parse_long_opt("output", av, &optarg))) {
|
|
|
|
options->file = fopen(optarg, "w");
|
2010-02-16 12:10:45 +08:00
|
|
|
if (!options->file)
|
2010-09-29 15:26:23 +08:00
|
|
|
die_errno("Could not open '%s'", optarg);
|
2008-03-10 10:43:39 +08:00
|
|
|
options->close_file = 1;
|
2010-08-05 16:22:52 +08:00
|
|
|
return argcount;
|
2008-03-10 10:43:39 +08:00
|
|
|
} else
|
2006-04-22 14:57:45 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2007-06-08 17:54:57 +08:00
|
|
|
static int diff_scoreopt_parse(const char *opt)
|
2006-04-22 14:57:45 +08:00
|
|
|
{
|
|
|
|
int opt1, opt2, cmd;
|
|
|
|
|
|
|
|
if (*opt++ != '-')
|
|
|
|
return -1;
|
|
|
|
cmd = *opt++;
|
2010-09-28 07:58:26 +08:00
|
|
|
if (cmd == '-') {
|
|
|
|
/* convert the long-form arguments into short-form versions */
|
|
|
|
if (!prefixcmp(opt, "break-rewrites")) {
|
|
|
|
opt += strlen("break-rewrites");
|
|
|
|
if (*opt == 0 || *opt++ == '=')
|
|
|
|
cmd = 'B';
|
2010-11-11 04:27:12 +08:00
|
|
|
} else if (!prefixcmp(opt, "find-copies")) {
|
|
|
|
opt += strlen("find-copies");
|
2010-09-28 07:58:26 +08:00
|
|
|
if (*opt == 0 || *opt++ == '=')
|
|
|
|
cmd = 'C';
|
2010-11-11 04:27:12 +08:00
|
|
|
} else if (!prefixcmp(opt, "find-renames")) {
|
|
|
|
opt += strlen("find-renames");
|
2010-09-28 07:58:26 +08:00
|
|
|
if (*opt == 0 || *opt++ == '=')
|
|
|
|
cmd = 'M';
|
|
|
|
}
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
if (cmd != 'M' && cmd != 'C' && cmd != 'B')
|
|
|
|
return -1; /* that is not a -M, -C nor -B option */
|
|
|
|
|
2010-09-28 07:58:25 +08:00
|
|
|
opt1 = parse_rename_score(&opt);
|
2006-04-22 14:57:45 +08:00
|
|
|
if (cmd != 'B')
|
|
|
|
opt2 = 0;
|
|
|
|
else {
|
|
|
|
if (*opt == 0)
|
|
|
|
opt2 = 0;
|
|
|
|
else if (*opt != '/')
|
|
|
|
return -1; /* we expect -B80/99 or -B80 */
|
|
|
|
else {
|
|
|
|
opt++;
|
2010-09-28 07:58:25 +08:00
|
|
|
opt2 = parse_rename_score(&opt);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (*opt != 0)
|
|
|
|
return -1;
|
|
|
|
return opt1 | (opt2 << 16);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct diff_queue_struct diff_queued_diff;
|
|
|
|
|
|
|
|
void diff_q(struct diff_queue_struct *queue, struct diff_filepair *dp)
|
|
|
|
{
|
|
|
|
if (queue->alloc <= queue->nr) {
|
|
|
|
queue->alloc = alloc_nr(queue->alloc);
|
|
|
|
queue->queue = xrealloc(queue->queue,
|
|
|
|
sizeof(dp) * queue->alloc);
|
|
|
|
}
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This is different from find_unique_abbrev() in that
|
|
|
|
* it stuffs the result with dots for alignment.
|
|
|
|
*/
|
|
|
|
const char *diff_unique_abbrev(const unsigned char *sha1, int len)
|
|
|
|
{
|
|
|
|
int abblen;
|
|
|
|
const char *abbrev;
|
|
|
|
if (len == 40)
|
|
|
|
return sha1_to_hex(sha1);
|
|
|
|
|
|
|
|
abbrev = find_unique_abbrev(sha1, len);
|
|
|
|
abblen = strlen(abbrev);
|
|
|
|
if (abblen < 37) {
|
|
|
|
static char hex[41];
|
|
|
|
if (len < abblen && abblen <= len + 2)
|
|
|
|
sprintf(hex, "%s%.*s", abbrev, len+3-abblen, "..");
|
|
|
|
else
|
|
|
|
sprintf(hex, "%s...", abbrev);
|
|
|
|
return hex;
|
|
|
|
}
|
|
|
|
return sha1_to_hex(sha1);
|
|
|
|
}
|
|
|
|
|
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';
|
2010-05-26 15:23:54 +08:00
|
|
|
if (opt->output_prefix) {
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
msg = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
fprintf(opt->file, "%s", msg->buf);
|
|
|
|
}
|
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 (!(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,
|
|
|
|
diff_unique_abbrev(p->one->sha1, opt->abbrev));
|
|
|
|
fprintf(opt->file, "%s ", diff_unique_abbrev(p->two->sha1, 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.
|
|
|
|
*/
|
|
|
|
if (one->sha1_valid && two->sha1_valid &&
|
2010-03-13 05:23:52 +08:00
|
|
|
!hashcmp(one->sha1, two->sha1) &&
|
|
|
|
!one->dirty_submodule && !two->dirty_submodule)
|
2006-04-22 14:57:45 +08:00
|
|
|
return 1; /* no change */
|
|
|
|
if (!one->sha1_valid && !two->sha1_valid)
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
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)))
|
|
|
|
return; /* no tree diffs in patch format */
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
int diff_queue_is_empty(void)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
|
|
|
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,
|
|
|
|
s->sha1_valid ? sha1_to_hex(s->sha1) : "");
|
|
|
|
fprintf(stderr, "queue[%d] %s size %lu flags %d\n",
|
|
|
|
x, one ? one : "",
|
|
|
|
s->size, s->xfrm_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
2006-08-18 02:54:57 +08:00
|
|
|
else if (hashcmp(p->one->sha1, p->two->sha1) ||
|
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 ||
|
2007-02-23 04:50:10 +08:00
|
|
|
is_null_sha1(p->one->sha1))
|
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);
|
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
|
|
|
}
|
|
|
|
|
2008-03-10 10:43:39 +08:00
|
|
|
static void show_file_mode_name(FILE *file, const char *newdelete, struct diff_filespec *fs)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
|
|
|
if (fs->mode)
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, " %s mode %06o ", newdelete, fs->mode);
|
2006-05-14 20:13:49 +08:00
|
|
|
else
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, " %s ", newdelete);
|
|
|
|
write_name_quoted(fs->path, file, '\n');
|
2006-05-14 20:13:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static void show_mode_change(FILE *file, struct diff_filepair *p, int show_name,
|
|
|
|
const char *line_prefix)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
|
|
|
if (p->one->mode && p->two->mode && p->one->mode != p->two->mode) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%s mode change %06o => %06o%c", line_prefix, p->one->mode,
|
|
|
|
p->two->mode, show_name ? ' ' : '\n');
|
2007-02-10 22:37:48 +08:00
|
|
|
if (show_name) {
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(p->two->path, file, '\n');
|
2007-02-10 22:37:48 +08:00
|
|
|
}
|
2006-05-14 20:13:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-26 15:23:54 +08:00
|
|
|
static void show_rename_copy(FILE *file, const char *renamecopy, struct diff_filepair *p,
|
|
|
|
const char *line_prefix)
|
2006-05-14 20:13:49 +08:00
|
|
|
{
|
2007-02-10 22:36:47 +08:00
|
|
|
char *names = pprint_rename(p->one->path, p->two->path);
|
2006-05-14 20:13:49 +08:00
|
|
|
|
2008-03-10 10:43:39 +08:00
|
|
|
fprintf(file, " %s %s (%d%%)\n", renamecopy, names, similarity_index(p));
|
2007-02-10 22:36:47 +08:00
|
|
|
free(names);
|
2010-05-26 15:23:54 +08:00
|
|
|
show_mode_change(file, p, 0, line_prefix);
|
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
|
|
|
{
|
2010-05-26 15:23:54 +08:00
|
|
|
FILE *file = opt->file;
|
|
|
|
char *line_prefix = "";
|
|
|
|
|
|
|
|
if (opt->output_prefix) {
|
|
|
|
struct strbuf *buf = opt->output_prefix(opt, opt->output_prefix_data);
|
|
|
|
line_prefix = buf->buf;
|
|
|
|
}
|
|
|
|
|
2006-05-14 20:13:49 +08:00
|
|
|
switch(p->status) {
|
|
|
|
case DIFF_STATUS_DELETED:
|
2010-05-26 15:23:54 +08:00
|
|
|
fputs(line_prefix, file);
|
2008-03-10 10:43:39 +08:00
|
|
|
show_file_mode_name(file, "delete", p->one);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_ADDED:
|
2010-05-26 15:23:54 +08:00
|
|
|
fputs(line_prefix, file);
|
2008-03-10 10:43:39 +08:00
|
|
|
show_file_mode_name(file, "create", p->two);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_COPIED:
|
2010-05-26 15:23:54 +08:00
|
|
|
fputs(line_prefix, file);
|
|
|
|
show_rename_copy(file, "copy", p, line_prefix);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_RENAMED:
|
2010-05-26 15:23:54 +08:00
|
|
|
fputs(line_prefix, file);
|
|
|
|
show_rename_copy(file, "rename", p, line_prefix);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (p->score) {
|
2010-05-26 15:23:54 +08:00
|
|
|
fprintf(file, "%s rewrite ", line_prefix);
|
2008-03-10 10:43:39 +08:00
|
|
|
write_name_quoted(p->two->path, file, ' ');
|
|
|
|
fprintf(file, "(%d%%)\n", similarity_index(p));
|
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
|
|
|
}
|
2010-05-26 15:23:54 +08:00
|
|
|
show_mode_change(file, p, !p->score, line_prefix);
|
2006-05-14 20:13:49 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-25 09:51:08 +08:00
|
|
|
struct patch_id_t {
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA_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
|
|
|
}
|
|
|
|
|
|
|
|
static void patch_id_consume(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
struct patch_id_t *data = priv;
|
|
|
|
int new_len;
|
|
|
|
|
|
|
|
/* Ignore line numbers when computing the SHA1 of the patch */
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 17:53:29 +08:00
|
|
|
if (!prefixcmp(line, "@@ -"))
|
2006-06-25 09:51:08 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
new_len = remove_space(line, len);
|
|
|
|
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA1_Update(data->ctx, line, new_len);
|
2006-06-25 09:51:08 +08:00
|
|
|
data->patchlen += new_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* returns 0 upon success, and writes result into sha1 */
|
|
|
|
static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA_CTX ctx;
|
2006-06-25 09:51:08 +08:00
|
|
|
struct patch_id_t data;
|
|
|
|
char buffer[PATH_MAX * 4 + 20];
|
|
|
|
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA1_Init(&ctx);
|
2006-06-25 09:51:08 +08:00
|
|
|
memset(&data, 0, sizeof(struct patch_id_t));
|
|
|
|
data.ctx = &ctx;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
diff_fill_sha1_info(p->one);
|
|
|
|
diff_fill_sha1_info(p->two);
|
|
|
|
if (fill_mmfile(&mf1, p->one) < 0 ||
|
|
|
|
fill_mmfile(&mf2, p->two) < 0)
|
|
|
|
return error("unable to read files to diff");
|
|
|
|
|
|
|
|
len1 = remove_space(p->one->path, strlen(p->one->path));
|
|
|
|
len2 = remove_space(p->two->path, strlen(p->two->path));
|
|
|
|
if (p->one->mode == 0)
|
|
|
|
len1 = snprintf(buffer, sizeof(buffer),
|
|
|
|
"diff--gita/%.*sb/%.*s"
|
|
|
|
"newfilemode%06o"
|
|
|
|
"---/dev/null"
|
|
|
|
"+++b/%.*s",
|
|
|
|
len1, p->one->path,
|
|
|
|
len2, p->two->path,
|
|
|
|
p->two->mode,
|
|
|
|
len2, p->two->path);
|
|
|
|
else if (p->two->mode == 0)
|
|
|
|
len1 = snprintf(buffer, sizeof(buffer),
|
|
|
|
"diff--gita/%.*sb/%.*s"
|
|
|
|
"deletedfilemode%06o"
|
|
|
|
"---a/%.*s"
|
|
|
|
"+++/dev/null",
|
|
|
|
len1, p->one->path,
|
|
|
|
len2, p->two->path,
|
|
|
|
p->one->mode,
|
|
|
|
len1, p->one->path);
|
|
|
|
else
|
|
|
|
len1 = snprintf(buffer, sizeof(buffer),
|
|
|
|
"diff--gita/%.*sb/%.*s"
|
|
|
|
"---a/%.*s"
|
|
|
|
"+++b/%.*s",
|
|
|
|
len1, p->one->path,
|
|
|
|
len2, p->two->path,
|
|
|
|
len1, p->one->path,
|
|
|
|
len2, p->two->path);
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA1_Update(&ctx, buffer, len1);
|
2006-06-25 09:51:08 +08:00
|
|
|
|
2010-08-15 15:20:43 +08:00
|
|
|
if (diff_filespec_is_binary(p->one) ||
|
|
|
|
diff_filespec_is_binary(p->two)) {
|
|
|
|
git_SHA1_Update(&ctx, sha1_to_hex(p->one->sha1), 40);
|
|
|
|
git_SHA1_Update(&ctx, sha1_to_hex(p->two->sha1), 40);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2010-05-02 21:04:41 +08:00
|
|
|
xpp.flags = 0;
|
2006-06-25 09:51:08 +08:00
|
|
|
xecfg.ctxlen = 3;
|
2010-09-19 17:59:28 +08:00
|
|
|
xecfg.flags = 0;
|
2008-08-14 14:18:22 +08:00
|
|
|
xdi_diff_outf(&mf1, &mf2, patch_id_consume, &data,
|
2010-05-05 04:41:34 +08:00
|
|
|
&xpp, &xecfg);
|
2006-06-25 09:51:08 +08:00
|
|
|
}
|
|
|
|
|
2008-10-02 02:05:20 +08:00
|
|
|
git_SHA1_Final(sha1, &ctx);
|
2006-06-25 09:51:08 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int diff_flush_patch_id(struct diff_options *options, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
int i;
|
|
|
|
int result = diff_get_patch_id(options, sha1);
|
|
|
|
|
|
|
|
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[] =
|
|
|
|
"inexact rename detection was skipped due to too many files.";
|
|
|
|
|
|
|
|
static const char degrade_cc_to_c_warning[] =
|
|
|
|
"only found copies from modified paths due to too many files.";
|
|
|
|
|
|
|
|
static const char rename_limit_advice[] =
|
|
|
|
"you may want to set your %s variable to at least "
|
|
|
|
"%d and retry the command.";
|
|
|
|
|
|
|
|
void diff_warn_rename_limit(const char *varname, int needed, int degraded_cc)
|
|
|
|
{
|
|
|
|
if (degraded_cc)
|
|
|
|
warning(degrade_cc_to_c_warning);
|
|
|
|
else if (needed)
|
|
|
|
warning(rename_limit_warning);
|
|
|
|
else
|
|
|
|
return;
|
|
|
|
if (0 < needed && needed < 32767)
|
|
|
|
warning(rename_limit_advice, varname, needed);
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
*/
|
2006-06-27 20:09:17 +08:00
|
|
|
if (!q->nr)
|
|
|
|
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
|
|
|
|
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 && DIFF_OPT_TST(options, DIRSTAT_BY_LINE))
|
|
|
|
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
|
|
|
|
2006-06-25 19:28:19 +08:00
|
|
|
memset(&diffstat, 0, sizeof(struct diffstat_t));
|
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))
|
2006-06-25 19:28:19 +08:00
|
|
|
diff_flush_stat(p, options, &diffstat);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
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);
|
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)
|
|
|
|
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 &&
|
|
|
|
DIFF_OPT_TST(options, EXIT_WITH_STATUS) &&
|
|
|
|
DIFF_OPT_TST(options, DIFF_FROM_CONTENTS)) {
|
|
|
|
/*
|
|
|
|
* run diff_flush_patch for the exit status. setting
|
|
|
|
* options->file to /dev/null should be safe, becaue we
|
|
|
|
* aren't supposed to produce any output anyway.
|
|
|
|
*/
|
|
|
|
if (options->close_file)
|
|
|
|
fclose(options->file);
|
|
|
|
options->file = fopen("/dev/null", "w");
|
|
|
|
if (!options->file)
|
|
|
|
die_errno("Could not open /dev/null");
|
|
|
|
options->close_file = 1;
|
|
|
|
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) {
|
2012-03-20 16:05:34 +08:00
|
|
|
if (options->output_prefix) {
|
|
|
|
struct strbuf *msg = NULL;
|
|
|
|
msg = options->output_prefix(options,
|
|
|
|
options->output_prefix_data);
|
|
|
|
fwrite(msg->buf, msg->len, 1, stdout);
|
|
|
|
}
|
2008-07-30 13:49:33 +08:00
|
|
|
putc(options->line_termination, options->file);
|
2006-06-27 20:09:17 +08:00
|
|
|
if (options->stat_sep) {
|
|
|
|
/* attach patch instead of inline */
|
2008-03-10 10:43:39 +08:00
|
|
|
fputs(options->stat_sep, options->file);
|
2006-06-27 20:09:17 +08:00
|
|
|
}
|
2006-06-25 01:21:53 +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);
|
|
|
|
}
|
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);
|
2008-03-10 10:43:39 +08:00
|
|
|
if (options->close_file)
|
|
|
|
fclose(options->file);
|
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).
|
|
|
|
*/
|
|
|
|
if (DIFF_OPT_TST(options, DIFF_FROM_CONTENTS)) {
|
|
|
|
if (options->found_changes)
|
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
|
|
|
else
|
|
|
|
DIFF_OPT_CLR(options, HAS_CHANGES);
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void diffcore_apply_filter(const char *filter)
|
|
|
|
{
|
|
|
|
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);
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
if (!filter)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (strchr(filter, DIFF_STATUS_FILTER_AON)) {
|
|
|
|
int found;
|
|
|
|
for (i = found = 0; !found && i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
if (((p->status == DIFF_STATUS_MODIFIED) &&
|
|
|
|
((p->score &&
|
|
|
|
strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||
|
|
|
|
(!p->score &&
|
|
|
|
strchr(filter, DIFF_STATUS_MODIFIED)))) ||
|
|
|
|
((p->status != DIFF_STATUS_MODIFIED) &&
|
|
|
|
strchr(filter, p->status)))
|
|
|
|
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];
|
|
|
|
|
|
|
|
if (((p->status == DIFF_STATUS_MODIFIED) &&
|
|
|
|
((p->score &&
|
|
|
|
strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||
|
|
|
|
(!p->score &&
|
|
|
|
strchr(filter, DIFF_STATUS_MODIFIED)))) ||
|
|
|
|
((p->status != DIFF_STATUS_MODIFIED) &&
|
|
|
|
strchr(filter, p->status)))
|
|
|
|
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 */
|
|
|
|
static int diff_filespec_is_identical(struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two)
|
|
|
|
{
|
2008-03-02 16:07:59 +08:00
|
|
|
if (S_ISGITLINK(one->mode))
|
|
|
|
return 0;
|
2007-09-08 18:30:22 +08:00
|
|
|
if (diff_populate_filespec(one, 0))
|
|
|
|
return 0;
|
|
|
|
if (diff_populate_filespec(two, 0))
|
|
|
|
return 0;
|
|
|
|
return !memcmp(one->data, two->data, one->size);
|
|
|
|
}
|
|
|
|
|
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];
|
|
|
|
|
|
|
|
/*
|
2010-02-04 13:23:18 +08:00
|
|
|
* 1. Entries that come from stat info dirtiness
|
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
|
|
|
* 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) ||
|
|
|
|
(p->one->sha1_valid && p->two->sha1_valid) ||
|
|
|
|
(p->one->mode != p->two->mode) ||
|
|
|
|
diff_populate_filespec(p->one, 1) ||
|
|
|
|
diff_populate_filespec(p->two, 1) ||
|
|
|
|
(p->one->size != p->two->size) ||
|
2007-09-08 18:30:22 +08:00
|
|
|
!diff_filespec_is_identical(p->one, p->two)) /* (2) */
|
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.
|
|
|
|
*/
|
2007-11-11 03:05:14 +08:00
|
|
|
if (!DIFF_OPT_TST(diffopt, 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);
|
|
|
|
}
|
|
|
|
|
|
|
|
void diffcore_fix_diff_index(struct diff_options *options)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
qsort(q->queue, q->nr, sizeof(q->queue[0]), diffnamecmp);
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void diffcore_std(struct diff_options *options)
|
|
|
|
{
|
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)
|
|
|
|
diffcore_break(options->break_opt);
|
|
|
|
if (options->detect_rename)
|
|
|
|
diffcore_rename(options);
|
|
|
|
if (options->break_opt != -1)
|
|
|
|
diffcore_merge_broken();
|
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
if (options->pickaxe)
|
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);
|
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();
|
2006-04-22 14:57:45 +08:00
|
|
|
diffcore_apply_filter(options->filter);
|
2007-03-15 02:12:13 +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
|
|
|
if (diff_queued_diff.nr && !DIFF_OPT_TST(options, DIFF_FROM_CONTENTS))
|
2007-11-11 03:05:14 +08:00
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
|
|
|
else
|
|
|
|
DIFF_OPT_CLR(options, HAS_CHANGES);
|
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
|
|
|
|
|
|
|
diff_warn_rename_limit("diff.renamelimit",
|
|
|
|
opt->needed_rename_limit,
|
|
|
|
opt->degraded_cc_to_c);
|
2007-12-14 15:40:27 +08:00
|
|
|
if (!DIFF_OPT_TST(opt, EXIT_WITH_STATUS) &&
|
|
|
|
!(opt->output_format & DIFF_FORMAT_CHECKDIFF))
|
|
|
|
return status;
|
|
|
|
if (DIFF_OPT_TST(opt, EXIT_WITH_STATUS) &&
|
|
|
|
DIFF_OPT_TST(opt, HAS_CHANGES))
|
|
|
|
result |= 01;
|
|
|
|
if ((opt->output_format & DIFF_FORMAT_CHECKDIFF) &&
|
|
|
|
DIFF_OPT_TST(opt, CHECK_FAILED))
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
return (DIFF_OPT_TST(opt, QUICK) &&
|
|
|
|
!opt->filter &&
|
|
|
|
DIFF_OPT_TST(opt, HAS_CHANGES));
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
unsigned orig_flags = options->flags;
|
|
|
|
if (!DIFF_OPT_TST(options, OVERRIDE_SUBMODULE_CONFIG))
|
|
|
|
set_diffopt_flags_from_submodule_config(options, path);
|
|
|
|
if (DIFF_OPT_TST(options, IGNORE_SUBMODULES))
|
|
|
|
ignored = 1;
|
|
|
|
options->flags = orig_flags;
|
|
|
|
return ignored;
|
|
|
|
}
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
void diff_addremove(struct diff_options *options,
|
|
|
|
int addremove, unsigned mode,
|
|
|
|
const unsigned char *sha1,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
int sha1_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.
|
|
|
|
*/
|
2007-11-11 03:05:14 +08:00
|
|
|
if (DIFF_OPT_TST(options, 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 != '+')
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
fill_filespec(one, sha1, sha1_valid, mode);
|
2010-01-19 04:26:18 +08:00
|
|
|
if (addremove != '-') {
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
fill_filespec(two, sha1, sha1_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);
|
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 (!DIFF_OPT_TST(options, DIFF_FROM_CONTENTS))
|
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
2006-04-22 14:57:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_change(struct diff_options *options,
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
|
|
|
const unsigned char *old_sha1,
|
|
|
|
const unsigned char *new_sha1,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
int old_sha1_valid, int new_sha1_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;
|
|
|
|
|
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;
|
|
|
|
|
2007-11-11 03:05:14 +08:00
|
|
|
if (DIFF_OPT_TST(options, REVERSE_DIFF)) {
|
2006-04-22 14:57:45 +08:00
|
|
|
unsigned tmp;
|
|
|
|
const unsigned char *tmp_c;
|
|
|
|
tmp = old_mode; old_mode = new_mode; new_mode = tmp;
|
|
|
|
tmp_c = old_sha1; old_sha1 = new_sha1; new_sha1 = tmp_c;
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
tmp = old_sha1_valid; old_sha1_valid = new_sha1_valid;
|
|
|
|
new_sha1_valid = tmp;
|
2010-01-19 04:26:18 +08:00
|
|
|
tmp = old_dirty_submodule; old_dirty_submodule = new_dirty_submodule;
|
|
|
|
new_dirty_submodule = tmp;
|
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);
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
fill_filespec(one, old_sha1, old_sha1_valid, old_mode);
|
|
|
|
fill_filespec(two, new_sha1, new_sha1_valid, new_mode);
|
2010-01-19 04:26:18 +08:00
|
|
|
one->dirty_submodule = old_dirty_submodule;
|
|
|
|
two->dirty_submodule = new_dirty_submodule;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
diff_queue(&diff_queued_diff, one, two);
|
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 (!DIFF_OPT_TST(options, DIFF_FROM_CONTENTS))
|
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
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
|
|
|
|
|
|
|
static char *run_textconv(const char *pgm, struct diff_filespec *spec,
|
|
|
|
size_t *outsize)
|
|
|
|
{
|
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;
|
2008-10-06 05:43:45 +08:00
|
|
|
const char *argv[3];
|
|
|
|
const char **arg = argv;
|
|
|
|
struct child_process child;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2010-03-31 01:36:03 +08:00
|
|
|
int err = 0;
|
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
|
|
|
temp = prepare_temp_file(spec->path, spec);
|
2008-10-06 05:43:45 +08:00
|
|
|
*arg++ = pgm;
|
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
|
|
|
*arg++ = temp->name;
|
2008-10-06 05:43:45 +08:00
|
|
|
*arg = NULL;
|
|
|
|
|
|
|
|
memset(&child, 0, sizeof(child));
|
2009-12-30 19:01:09 +08:00
|
|
|
child.use_shell = 1;
|
2008-10-06 05:43:45 +08:00
|
|
|
child.argv = argv;
|
|
|
|
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
|
|
|
|
2010-06-07 23:23:36 +08:00
|
|
|
size_t fill_textconv(struct userdiff_driver *driver,
|
|
|
|
struct diff_filespec *df,
|
|
|
|
char **outbuf)
|
2010-04-02 08:09:26 +08:00
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
|
2010-04-02 08:12:15 +08:00
|
|
|
if (!driver || !driver->textconv) {
|
2010-04-02 08:09:26 +08:00
|
|
|
if (!DIFF_FILE_VALID(df)) {
|
|
|
|
*outbuf = "";
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (diff_populate_filespec(df, 0))
|
|
|
|
die("unable to read files to diff");
|
|
|
|
*outbuf = df->data;
|
|
|
|
return df->size;
|
|
|
|
}
|
|
|
|
|
2010-12-18 22:54:12 +08:00
|
|
|
if (driver->textconv_cache && df->sha1_valid) {
|
2010-04-02 08:12:15 +08:00
|
|
|
*outbuf = notes_cache_get(driver->textconv_cache, df->sha1,
|
|
|
|
&size);
|
|
|
|
if (*outbuf)
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
*outbuf = run_textconv(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
|
|
|
|
2010-12-18 22:54:12 +08:00
|
|
|
if (driver->textconv_cache && df->sha1_valid) {
|
2010-04-02 08:12:15 +08:00
|
|
|
/* ignore errors, as we might be in a readonly repository */
|
|
|
|
notes_cache_put(driver->textconv_cache, df->sha1, *outbuf,
|
|
|
|
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
|
|
|
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
if (!DIFF_OPT_TST(opt, EXIT_WITH_STATUS) &&
|
|
|
|
check_pager_config("diff") != 0)
|
|
|
|
setup_pager();
|
|
|
|
}
|