2006-04-22 06:57:45 +00: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-04 23:51:44 +00:00
|
|
|
#include "delta.h"
|
2006-04-22 06:57:45 +00:00
|
|
|
#include "xdiff-interface.h"
|
2006-09-08 08:03:18 +00:00
|
|
|
#include "color.h"
|
2007-04-13 06:05:29 +00:00
|
|
|
#include "attr.h"
|
2007-10-19 19:47:56 +00:00
|
|
|
#include "run-command.h"
|
2008-01-02 09:50:11 +00:00
|
|
|
#include "utf8.h"
|
2008-10-05 21:43:21 +00: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 06:02:35 +00:00
|
|
|
#include "sigchain.h"
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-12-14 11:15:57 +00:00
|
|
|
#ifdef NO_FAST_WORKING_DIRECTORY
|
|
|
|
#define FAST_WORKING_DIRECTORY 0
|
|
|
|
#else
|
|
|
|
#define FAST_WORKING_DIRECTORY 1
|
|
|
|
#endif
|
|
|
|
|
2006-08-15 17:23:48 +00:00
|
|
|
static int diff_detect_rename_default;
|
2008-04-30 17:24:43 +00:00
|
|
|
static int diff_rename_limit_default = 200;
|
2008-08-15 11:39:26 +00:00
|
|
|
static int diff_suppress_blank_empty;
|
2008-02-18 07:26:03 +00:00
|
|
|
int diff_use_color_default = -1;
|
2009-01-21 03:46:57 +00:00
|
|
|
static const char *diff_word_regex_cfg;
|
2007-12-17 13:42:20 +00:00
|
|
|
static const char *external_diff_cmd_cfg;
|
2007-08-31 20:13:42 +00:00
|
|
|
int diff_auto_refresh_index = 1;
|
2008-08-19 03:08:09 +00:00
|
|
|
static int diff_mnemonic_prefix;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-09-08 08:03:18 +00:00
|
|
|
static char diff_colors[][COLOR_MAXLEN] = {
|
2006-07-13 16:06:12 +00:00
|
|
|
"\033[m", /* reset */
|
2006-09-23 05:48:39 +00:00
|
|
|
"", /* PLAIN (normal) */
|
|
|
|
"\033[1m", /* METAINFO (bold) */
|
|
|
|
"\033[36m", /* FRAGINFO (cyan) */
|
|
|
|
"\033[31m", /* OLD (red) */
|
|
|
|
"\033[32m", /* NEW (green) */
|
|
|
|
"\033[33m", /* COMMIT (yellow) */
|
|
|
|
"\033[41m", /* WHITESPACE (red background) */
|
2006-06-13 16:45:44 +00:00
|
|
|
};
|
|
|
|
|
2008-10-05 21:43:45 +00:00
|
|
|
static void diff_filespec_load_driver(struct diff_filespec *one);
|
|
|
|
static char *run_textconv(const char *, struct diff_filespec *, size_t *);
|
|
|
|
|
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 11:06:23 +00: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 09:24:18 +00:00
|
|
|
if (!strcasecmp(var+ofs, "commit"))
|
|
|
|
return DIFF_COMMIT;
|
2006-09-23 05:48:39 +00:00
|
|
|
if (!strcasecmp(var+ofs, "whitespace"))
|
|
|
|
return DIFF_WHITESPACE;
|
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 11:06:23 +00:00
|
|
|
die("bad config variable '%s'", var);
|
|
|
|
}
|
|
|
|
|
2006-07-08 08:05:16 +00: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-14 17:46:53 +00: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 11:06:23 +00:00
|
|
|
{
|
2006-12-13 09:13:28 +00:00
|
|
|
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
|
2007-12-06 01:26:11 +00:00
|
|
|
diff_use_color_default = git_config_colorbool(var, value, -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 11:06:23 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2006-07-07 11:01:23 +00:00
|
|
|
if (!strcmp(var, "diff.renames")) {
|
|
|
|
if (!value)
|
|
|
|
diff_detect_rename_default = DIFF_DETECT_RENAME;
|
|
|
|
else if (!strcasecmp(value, "copies") ||
|
|
|
|
!strcasecmp(value, "copy"))
|
|
|
|
diff_detect_rename_default = DIFF_DETECT_COPY;
|
|
|
|
else if (git_config_bool(var,value))
|
|
|
|
diff_detect_rename_default = DIFF_DETECT_RENAME;
|
|
|
|
return 0;
|
|
|
|
}
|
2007-08-31 20:13:42 +00:00
|
|
|
if (!strcmp(var, "diff.autorefreshindex")) {
|
|
|
|
diff_auto_refresh_index = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-08-19 03:08:09 +00:00
|
|
|
if (!strcmp(var, "diff.mnemonicprefix")) {
|
|
|
|
diff_mnemonic_prefix = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-07-05 05:24:43 +00:00
|
|
|
if (!strcmp(var, "diff.external"))
|
|
|
|
return git_config_string(&external_diff_cmd_cfg, var, value);
|
2009-01-21 03:46:57 +00:00
|
|
|
if (!strcmp(var, "diff.wordregex"))
|
|
|
|
return git_config_string(&diff_word_regex_cfg, var, value);
|
2007-04-23 00:52:55 +00:00
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
return git_diff_basic_config(var, value, cb);
|
2008-01-04 08:59:34 +00:00
|
|
|
}
|
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
int git_diff_basic_config(const char *var, const char *value, void *cb)
|
2008-01-04 08:59:34 +00:00
|
|
|
{
|
2008-08-05 18:27:30 +00:00
|
|
|
if (!strcmp(var, "diff.renamelimit")) {
|
|
|
|
diff_rename_limit_default = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-10-26 04:45:55 +00:00
|
|
|
switch (userdiff_config(var, value)) {
|
|
|
|
case 0: break;
|
|
|
|
case -1: return -1;
|
|
|
|
default: return 0;
|
|
|
|
}
|
|
|
|
|
2007-02-20 09:55:07 +00: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 11:06:23 +00:00
|
|
|
int slot = parse_diff_color_slot(var, 11);
|
2008-02-11 18:53:56 +00:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2006-09-08 08:03:18 +00: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 11:06:23 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2007-04-23 00:52:55 +00:00
|
|
|
|
2008-08-15 11:39:26 +00:00
|
|
|
/* like GNU diff's --suppress-blank-empty option */
|
2009-01-20 21:08:33 +00:00
|
|
|
if (!strcmp(var, "diff.suppressblankempty") ||
|
|
|
|
/* for backwards compatibility */
|
|
|
|
!strcmp(var, "diff.suppress-blank-empty")) {
|
2008-08-15 11:39:26 +00:00
|
|
|
diff_suppress_blank_empty = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
return git_color_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 11:06:23 +00:00
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-09 19:12:12 +00:00
|
|
|
struct strbuf res = STRBUF_INIT;
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00: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 06:57:45 +00:00
|
|
|
}
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&res, NULL);
|
2006-04-22 06:57:45 +00: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 13:42:20 +00:00
|
|
|
if (!external_diff_cmd)
|
|
|
|
external_diff_cmd = external_diff_cmd_cfg;
|
2006-04-22 06:57:45 +00: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 13:35:46 +00:00
|
|
|
char tmp_path[PATH_MAX];
|
2006-04-22 06:57:45 +00:00
|
|
|
} diff_temp[2];
|
|
|
|
|
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 05:59:56 +00: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 13:36:14 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(diff_temp); i++) {
|
|
|
|
if (diff_temp[i].name == diff_temp[i].tmp_path)
|
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 05:59:56 +00:00
|
|
|
unlink(diff_temp[i].name);
|
2009-02-12 13:36:14 +00: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 05:59:56 +00: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 06:02:35 +00: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 05:59:56 +00:00
|
|
|
raise(signo);
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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;
|
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void print_line_count(FILE *file, int count)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
switch (count) {
|
|
|
|
case 0:
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "0,0");
|
2006-04-22 06:57:45 +00:00
|
|
|
break;
|
|
|
|
case 1:
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "1");
|
2006-04-22 06:57:45 +00:00
|
|
|
break;
|
|
|
|
default:
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "1,%d", count);
|
2006-04-22 06:57:45 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void copy_file_with_prefix(FILE *file,
|
|
|
|
int prefix, const char *data, int size,
|
2008-02-25 19:24:48 +00:00
|
|
|
const char *set, const char *reset)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int ch, nl_just_seen = 1;
|
|
|
|
while (0 < size--) {
|
|
|
|
ch = *data++;
|
2007-02-20 14:08:46 +00:00
|
|
|
if (nl_just_seen) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(set, file);
|
|
|
|
putc(prefix, file);
|
2007-02-20 14:08:46 +00:00
|
|
|
}
|
|
|
|
if (ch == '\n') {
|
2006-04-22 06:57:45 +00:00
|
|
|
nl_just_seen = 1;
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(reset, file);
|
2007-02-20 14:08:46 +00:00
|
|
|
} else
|
2006-04-22 06:57:45 +00:00
|
|
|
nl_just_seen = 0;
|
2008-03-10 02:43:39 +00:00
|
|
|
putc(ch, file);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
if (!nl_just_seen)
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "%s\n\\ No newline at end of file\n", reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void emit_rewrite_diff(const char *name_a,
|
|
|
|
const char *name_b,
|
|
|
|
struct diff_filespec *one,
|
2007-02-20 14:08:46 +00:00
|
|
|
struct diff_filespec *two,
|
2008-12-09 08:13:21 +00:00
|
|
|
const char *textconv_one,
|
|
|
|
const char *textconv_two,
|
2007-12-18 19:32:14 +00:00
|
|
|
struct diff_options *o)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int lc_a, lc_b;
|
2007-12-18 19:32:14 +00:00
|
|
|
int color_diff = DIFF_OPT_TST(o, COLOR_DIFF);
|
2006-09-22 23:17:58 +00:00
|
|
|
const char *name_a_tab, *name_b_tab;
|
2007-02-20 14:08:46 +00:00
|
|
|
const char *metainfo = diff_get_color(color_diff, DIFF_METAINFO);
|
|
|
|
const char *fraginfo = diff_get_color(color_diff, DIFF_FRAGINFO);
|
|
|
|
const char *old = diff_get_color(color_diff, DIFF_FILE_OLD);
|
|
|
|
const char *new = diff_get_color(color_diff, DIFF_FILE_NEW);
|
|
|
|
const char *reset = diff_get_color(color_diff, DIFF_RESET);
|
2007-12-27 01:13:36 +00:00
|
|
|
static struct strbuf a_name = STRBUF_INIT, b_name = STRBUF_INIT;
|
2008-08-19 03:08:09 +00:00
|
|
|
const char *a_prefix, *b_prefix;
|
2008-12-09 08:13:21 +00:00
|
|
|
const char *data_one, *data_two;
|
|
|
|
size_t size_one, size_two;
|
2008-08-19 03:08:09 +00: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-22 23:17:58 +00:00
|
|
|
|
2007-02-24 09:42:06 +00:00
|
|
|
name_a += (*name_a == '/');
|
|
|
|
name_b += (*name_b == '/');
|
2006-09-22 23:17:58 +00:00
|
|
|
name_a_tab = strchr(name_a, ' ') ? "\t" : "";
|
|
|
|
name_b_tab = strchr(name_b, ' ') ? "\t" : "";
|
|
|
|
|
2007-12-27 01:13:36 +00:00
|
|
|
strbuf_reset(&a_name);
|
|
|
|
strbuf_reset(&b_name);
|
2008-08-19 03:08:09 +00: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 01:13:36 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
diff_populate_filespec(one, 0);
|
|
|
|
diff_populate_filespec(two, 0);
|
2008-12-09 08:13:21 +00:00
|
|
|
if (textconv_one) {
|
|
|
|
data_one = run_textconv(textconv_one, one, &size_one);
|
|
|
|
if (!data_one)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
data_one = one->data;
|
|
|
|
size_one = one->size;
|
|
|
|
}
|
|
|
|
if (textconv_two) {
|
|
|
|
data_two = run_textconv(textconv_two, two, &size_two);
|
|
|
|
if (!data_two)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
data_two = two->data;
|
|
|
|
size_two = two->size;
|
|
|
|
}
|
|
|
|
|
|
|
|
lc_a = count_lines(data_one, size_one);
|
|
|
|
lc_b = count_lines(data_two, size_two);
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file,
|
|
|
|
"%s--- %s%s%s\n%s+++ %s%s%s\n%s@@ -",
|
|
|
|
metainfo, a_name.buf, name_a_tab, reset,
|
|
|
|
metainfo, b_name.buf, name_b_tab, reset, fraginfo);
|
|
|
|
print_line_count(o->file, lc_a);
|
|
|
|
fprintf(o->file, " +");
|
|
|
|
print_line_count(o->file, lc_b);
|
|
|
|
fprintf(o->file, " @@%s\n", reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (lc_a)
|
2008-12-09 08:13:21 +00:00
|
|
|
copy_file_with_prefix(o->file, '-', data_one, size_one, old, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (lc_b)
|
2008-12-09 08:13:21 +00:00
|
|
|
copy_file_with_prefix(o->file, '+', data_two, size_two, new, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int fill_mmfile(mmfile_t *mf, struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one)) {
|
2006-06-24 17:20:32 +00:00
|
|
|
mf->ptr = (char *)""; /* does not matter */
|
2006-04-22 06:57:45 +00:00
|
|
|
mf->size = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else if (diff_populate_filespec(one, 0))
|
|
|
|
return -1;
|
2008-10-05 21:43:45 +00: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 04:44:53 +00:00
|
|
|
mf->ptr = one->data;
|
|
|
|
mf->size = one->size;
|
2006-04-22 06:57:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
struct diff_words_orig {
|
|
|
|
const char *begin, *end;
|
|
|
|
} *orig;
|
|
|
|
int orig_nr, orig_alloc;
|
2006-07-28 21:56:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void diff_words_append(char *line, unsigned long len,
|
|
|
|
struct diff_words_buffer *buffer)
|
|
|
|
{
|
2009-01-17 16:29:43 +00:00
|
|
|
ALLOC_GROW(buffer->text.ptr, buffer->text.size + len, buffer->alloc);
|
2006-07-28 21:56:15 +00:00
|
|
|
line++;
|
|
|
|
len--;
|
|
|
|
memcpy(buffer->text.ptr + buffer->text.size, line, len);
|
|
|
|
buffer->text.size += len;
|
2009-01-17 16:29:45 +00:00
|
|
|
buffer->text.ptr[buffer->text.size] = '\0';
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
const char *current_plus;
|
2008-03-10 02:43:39 +00:00
|
|
|
FILE *file;
|
2009-01-17 16:29:45 +00:00
|
|
|
regex_t *word_regex;
|
2006-07-28 21:56:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
struct diff_words_data *diff_words = priv;
|
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-17 16:29:44 +00:00
|
|
|
int minus_first, minus_len, plus_first, plus_len;
|
|
|
|
const char *minus_begin, *minus_end, *plus_begin, *plus_end;
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
if (line[0] != '@' || parse_hunk_header(line, len,
|
|
|
|
&minus_first, &minus_len, &plus_first, &plus_len))
|
2006-07-28 21:56:15 +00:00
|
|
|
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-17 16:29:44 +00: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;
|
|
|
|
|
|
|
|
if (diff_words->current_plus != plus_begin)
|
|
|
|
fwrite(diff_words->current_plus,
|
|
|
|
plus_begin - diff_words->current_plus, 1,
|
|
|
|
diff_words->file);
|
|
|
|
if (minus_begin != minus_end)
|
|
|
|
color_fwrite_lines(diff_words->file,
|
|
|
|
diff_get_color(1, DIFF_FILE_OLD),
|
|
|
|
minus_end - minus_begin, minus_begin);
|
|
|
|
if (plus_begin != plus_end)
|
|
|
|
color_fwrite_lines(diff_words->file,
|
|
|
|
diff_get_color(1, DIFF_FILE_NEW),
|
|
|
|
plus_end - plus_begin, plus_begin);
|
|
|
|
|
|
|
|
diff_words->current_plus = plus_end;
|
2006-07-28 21:56:15 +00:00
|
|
|
}
|
|
|
|
|
2009-01-17 16:29:45 +00: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-28 21:56:15 +00:00
|
|
|
}
|
|
|
|
|
2009-01-17 16:29:45 +00:00
|
|
|
/* find the next word */
|
|
|
|
while (*begin < buffer->size && isspace(buffer->ptr[*begin]))
|
|
|
|
(*begin)++;
|
|
|
|
if (*begin >= buffer->size)
|
|
|
|
return -1;
|
2006-07-28 21:56:15 +00:00
|
|
|
|
2009-01-17 16:29:45 +00:00
|
|
|
/* find the end of the word */
|
|
|
|
*end = *begin + 1;
|
|
|
|
while (*end < buffer->size && !isspace(buffer->ptr[*end]))
|
|
|
|
(*end)++;
|
|
|
|
|
|
|
|
return 0;
|
2006-07-28 21:56:15 +00:00
|
|
|
}
|
|
|
|
|
2009-01-17 16:29:43 +00: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-17 16:29:44 +00: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-17 16:29:43 +00:00
|
|
|
*/
|
2009-01-17 16:29:45 +00:00
|
|
|
static void diff_words_fill(struct diff_words_buffer *buffer, mmfile_t *out,
|
|
|
|
regex_t *word_regex)
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
int i, j;
|
2009-01-17 16:29:45 +00:00
|
|
|
long alloc = 0;
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
out->size = 0;
|
2009-01-17 16:29:45 +00:00
|
|
|
out->ptr = NULL;
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00: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-17 16:29:45 +00: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-17 16:29:44 +00: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-17 16:29:45 +00: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-17 16:29:44 +00: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-28 21:56:15 +00: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;
|
|
|
|
xdemitcb_t ecb;
|
|
|
|
mmfile_t 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-17 16:29:44 +00:00
|
|
|
/* special case: only removal */
|
|
|
|
if (!diff_words->plus.text.size) {
|
|
|
|
color_fwrite_lines(diff_words->file,
|
|
|
|
diff_get_color(1, DIFF_FILE_OLD),
|
|
|
|
diff_words->minus.text.size, diff_words->minus.text.ptr);
|
|
|
|
diff_words->minus.text.size = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
diff_words->current_plus = diff_words->plus.text.ptr;
|
2006-07-28 21:56:15 +00:00
|
|
|
|
2008-10-25 13:30:37 +00:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-04 18:05:46 +00:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2009-01-17 16:29:45 +00:00
|
|
|
diff_words_fill(&diff_words->minus, &minus, diff_words->word_regex);
|
|
|
|
diff_words_fill(&diff_words->plus, &plus, diff_words->word_regex);
|
2006-07-28 21:56:15 +00:00
|
|
|
xpp.flags = XDF_NEED_MINIMAL;
|
2009-01-17 16:29:45 +00: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-17 16:29:44 +00:00
|
|
|
xecfg.ctxlen = 0;
|
2008-08-14 06:18:22 +00:00
|
|
|
xdi_diff_outf(&minus, &plus, fn_out_diff_words_aux, diff_words,
|
|
|
|
&xpp, &xecfg, &ecb);
|
2006-07-28 21:56:15 +00: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-17 16:29:44 +00:00
|
|
|
if (diff_words->current_plus != diff_words->plus.text.ptr +
|
|
|
|
diff_words->plus.text.size)
|
|
|
|
fwrite(diff_words->current_plus,
|
|
|
|
diff_words->plus.text.ptr + diff_words->plus.text.size
|
|
|
|
- diff_words->current_plus, 1,
|
|
|
|
diff_words->file);
|
2006-07-28 21:56:15 +00:00
|
|
|
diff_words->minus.text.size = diff_words->plus.text.size = 0;
|
|
|
|
}
|
|
|
|
|
2008-01-02 09:50:11 +00:00
|
|
|
typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
struct emit_callback {
|
2006-06-13 16:45:44 +00:00
|
|
|
int nparents, color_diff;
|
2007-12-06 08:14:14 +00:00
|
|
|
unsigned ws_rule;
|
2008-01-02 09:50:11 +00:00
|
|
|
sane_truncate_fn truncate;
|
2006-04-22 06:57:45 +00:00
|
|
|
const char **label_path;
|
2006-07-28 21:56:15 +00:00
|
|
|
struct diff_words_data *diff_words;
|
2007-02-25 22:34:54 +00:00
|
|
|
int *found_changesp;
|
2008-03-10 02:43:39 +00:00
|
|
|
FILE *file;
|
2006-04-22 06:57:45 +00:00
|
|
|
};
|
|
|
|
|
2006-07-28 21:56:15 +00:00
|
|
|
static void free_diff_words_data(struct emit_callback *ecbdata)
|
|
|
|
{
|
|
|
|
if (ecbdata->diff_words) {
|
|
|
|
/* flush buffers */
|
|
|
|
if (ecbdata->diff_words->minus.text.size ||
|
|
|
|
ecbdata->diff_words->plus.text.size)
|
|
|
|
diff_words_show(ecbdata->diff_words);
|
|
|
|
|
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-01-31 17:26:32 +00: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-17 16:29:44 +00: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-01-31 17:26:32 +00: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-17 16:29:44 +00:00
|
|
|
free (ecbdata->diff_words->plus.orig);
|
2009-01-17 16:29:45 +00:00
|
|
|
free(ecbdata->diff_words->word_regex);
|
2006-07-28 21:56:15 +00:00
|
|
|
free(ecbdata->diff_words);
|
|
|
|
ecbdata->diff_words = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-23 09:24:18 +00:00
|
|
|
const char *diff_get_color(int diff_use_color, enum color_diff ix)
|
2006-06-13 16:45:44 +00:00
|
|
|
{
|
|
|
|
if (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-22 20:53:31 +00:00
|
|
|
return diff_colors[ix];
|
|
|
|
return "";
|
2006-06-13 16:45:44 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void emit_line(FILE *file, const char *set, const char *reset, const char *line, int len)
|
2006-09-23 05:48:39 +00:00
|
|
|
{
|
2008-08-28 02:48:01 +00:00
|
|
|
int has_trailing_newline, has_trailing_carriage_return;
|
|
|
|
|
|
|
|
has_trailing_newline = (len > 0 && line[len-1] == '\n');
|
2008-06-17 00:37:21 +00:00
|
|
|
if (has_trailing_newline)
|
diff: reset color before printing newline
It worked that way since commit 50f575fc (Tweak diff colors,
2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13)
changed it. This patch restores the old behaviour.
Besides Linus' arguments in the log message of 50f575fc, resetting color
before printing newline is also important to keep 'git add --patch'
happy. If the last line(s) of a file are removed, then that hunk will
end with a colored line. However, if the newline comes before the color
reset, then the diff output will have an additional line at the end
containing only the reset sequence. This causes trouble in
git-add--interactive.perl's parse_diff function, because @colored will
have one more element than @diff, and that last element will contain the
color reset. The elements of these arrays will then be copied to @hunk,
but only as many as the number of elements in @diff. As a result the
last color reset is lost and all subsequent terminal output will be
printed in color.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-16 22:00:02 +00:00
|
|
|
len--;
|
2008-08-28 02:48:01 +00:00
|
|
|
has_trailing_carriage_return = (len > 0 && line[len-1] == '\r');
|
|
|
|
if (has_trailing_carriage_return)
|
|
|
|
len--;
|
diff: reset color before printing newline
It worked that way since commit 50f575fc (Tweak diff colors,
2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13)
changed it. This patch restores the old behaviour.
Besides Linus' arguments in the log message of 50f575fc, resetting color
before printing newline is also important to keep 'git add --patch'
happy. If the last line(s) of a file are removed, then that hunk will
end with a colored line. However, if the newline comes before the color
reset, then the diff output will have an additional line at the end
containing only the reset sequence. This causes trouble in
git-add--interactive.perl's parse_diff function, because @colored will
have one more element than @diff, and that last element will contain the
color reset. The elements of these arrays will then be copied to @hunk,
but only as many as the number of elements in @diff. As a result the
last color reset is lost and all subsequent terminal output will be
printed in color.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-16 22:00:02 +00:00
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(set, file);
|
|
|
|
fwrite(line, len, 1, file);
|
|
|
|
fputs(reset, file);
|
2008-08-28 02:48:01 +00:00
|
|
|
if (has_trailing_carriage_return)
|
|
|
|
fputc('\r', file);
|
2008-06-17 00:37:21 +00:00
|
|
|
if (has_trailing_newline)
|
|
|
|
fputc('\n', file);
|
2006-09-23 05:48:39 +00:00
|
|
|
}
|
|
|
|
|
2007-02-18 16:27:24 +00:00
|
|
|
static void emit_add_line(const char *reset, struct emit_callback *ecbdata, const char *line, int len)
|
|
|
|
{
|
|
|
|
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)
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file, set, reset, line, len);
|
2007-12-13 13:32:29 +00:00
|
|
|
else {
|
|
|
|
/* Emit just the prefix, then the rest. */
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file, set, reset, line, ecbdata->nparents);
|
2008-06-26 22:35:21 +00:00
|
|
|
ws_check_emit(line + ecbdata->nparents,
|
|
|
|
len - ecbdata->nparents, ecbdata->ws_rule,
|
|
|
|
ecbdata->file, set, reset, ws);
|
2007-12-13 13:32:29 +00:00
|
|
|
}
|
2007-02-18 16:27:24 +00:00
|
|
|
}
|
|
|
|
|
2008-01-02 09:50:11 +00: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;
|
|
|
|
}
|
|
|
|
|
2006-06-13 16:45:44 +00:00
|
|
|
static void fn_out_consume(void *priv, char *line, unsigned long len)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int i;
|
2006-09-23 05:48:39 +00:00
|
|
|
int color;
|
2006-04-22 06:57:45 +00:00
|
|
|
struct emit_callback *ecbdata = priv;
|
2008-01-17 15:03:06 +00: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 09:24:18 +00:00
|
|
|
const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2007-02-25 22:34:54 +00:00
|
|
|
*(ecbdata->found_changesp) = 1;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (ecbdata->label_path[0]) {
|
2006-09-22 23:17:58 +00: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" : "";
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(ecbdata->file, "%s--- %s%s%s\n",
|
|
|
|
meta, ecbdata->label_path[0], reset, name_a_tab);
|
|
|
|
fprintf(ecbdata->file, "%s+++ %s%s%s\n",
|
|
|
|
meta, ecbdata->label_path[1], reset, name_b_tab);
|
2006-04-22 06:57:45 +00:00
|
|
|
ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
|
|
|
|
}
|
2006-06-13 16:45:44 +00:00
|
|
|
|
2008-08-15 11:39:26 +00:00
|
|
|
if (diff_suppress_blank_empty
|
|
|
|
&& len == 2 && line[0] == ' ' && line[1] == '\n') {
|
|
|
|
line[0] = '\n';
|
|
|
|
len = 1;
|
|
|
|
}
|
|
|
|
|
2006-06-13 16:45:44 +00:00
|
|
|
/* This is not really necessary for now because
|
|
|
|
* this codepath only deals with two-way diffs.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < len && line[i] == '@'; i++)
|
|
|
|
;
|
|
|
|
if (2 <= i && i < len && line[i] == ' ') {
|
|
|
|
ecbdata->nparents = i - 1;
|
2008-01-02 09:50:11 +00:00
|
|
|
len = sane_truncate_line(ecbdata, line, len);
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file,
|
|
|
|
diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
|
2006-09-23 05:48:39 +00:00
|
|
|
reset, line, len);
|
2008-01-02 09:50:11 +00:00
|
|
|
if (line[len-1] != '\n')
|
2008-03-10 02:43:39 +00:00
|
|
|
putc('\n', ecbdata->file);
|
2006-09-23 05:48:39 +00:00
|
|
|
return;
|
2006-06-13 16:45:44 +00:00
|
|
|
}
|
2006-09-23 05:48:39 +00:00
|
|
|
|
|
|
|
if (len < ecbdata->nparents) {
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file, reset, reset, line, len);
|
2006-09-23 05:48:39 +00:00
|
|
|
return;
|
2006-06-13 16:45:44 +00:00
|
|
|
}
|
2006-09-23 05:48:39 +00:00
|
|
|
|
|
|
|
color = DIFF_PLAIN;
|
|
|
|
if (ecbdata->diff_words && ecbdata->nparents != 1)
|
|
|
|
/* fall back to normal diff */
|
|
|
|
free_diff_words_data(ecbdata);
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
if (ecbdata->diff_words->minus.text.size ||
|
|
|
|
ecbdata->diff_words->plus.text.size)
|
|
|
|
diff_words_show(ecbdata->diff_words);
|
|
|
|
line++;
|
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-22 20:53:31 +00:00
|
|
|
len--;
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file, plain, reset, line, len);
|
2006-09-23 05:48:39 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (i = 0; i < ecbdata->nparents && len; i++) {
|
|
|
|
if (line[i] == '-')
|
|
|
|
color = DIFF_FILE_OLD;
|
|
|
|
else if (line[i] == '+')
|
|
|
|
color = DIFF_FILE_NEW;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (color != DIFF_FILE_NEW) {
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_line(ecbdata->file,
|
|
|
|
diff_get_color(ecbdata->color_diff, color),
|
2006-09-23 05:48:39 +00:00
|
|
|
reset, line, len);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
emit_add_line(reset, ecbdata, line, len);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *pprint_rename(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
const char *old = a;
|
|
|
|
const char *new = b;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf name = STRBUF_INIT;
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
int a_midlen, b_midlen;
|
2007-02-10 14:39:00 +00: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-19 22:42:15 +00:00
|
|
|
quote_c_style(a, &name, NULL, 0);
|
|
|
|
strbuf_addstr(&name, " => ");
|
|
|
|
quote_c_style(b, &name, NULL, 0);
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&name, NULL);
|
2007-02-10 14:39:00 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00: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 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
strbuf_add(&name, a, pfx_length);
|
|
|
|
strbuf_addch(&name, '{');
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00: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 06:57:45 +00:00
|
|
|
}
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&name, NULL);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct diffstat_t {
|
|
|
|
int nr;
|
|
|
|
int alloc;
|
|
|
|
struct diffstat_file {
|
2007-12-12 07:46:30 +00:00
|
|
|
char *from_name;
|
2006-04-22 06:57:45 +00:00
|
|
|
char *name;
|
2007-12-12 07:46:30 +00:00
|
|
|
char *print_name;
|
2006-04-22 06:57:45 +00:00
|
|
|
unsigned is_unmerged:1;
|
|
|
|
unsigned is_binary:1;
|
|
|
|
unsigned is_renamed:1;
|
|
|
|
unsigned int added, deleted;
|
|
|
|
} **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 07:46:30 +00:00
|
|
|
x->from_name = xstrdup(name_a);
|
|
|
|
x->name = xstrdup(name_b);
|
2006-04-22 06:57:45 +00:00
|
|
|
x->is_renamed = 1;
|
|
|
|
}
|
2007-12-12 07:46:30 +00:00
|
|
|
else {
|
|
|
|
x->from_name = NULL;
|
2006-09-02 04:16:31 +00:00
|
|
|
x->name = xstrdup(name_a);
|
2007-12-12 07:46:30 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00: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 13:40:29 +00:00
|
|
|
const char mime_boundary_leader[] = "------------";
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
static int scale_linear(int it, int width, int max_change)
|
|
|
|
{
|
|
|
|
/*
|
2006-09-28 15:37:39 +00:00
|
|
|
* make sure that at least one '-' is printed if there were deletions,
|
|
|
|
* and likewise for '+'.
|
2006-09-27 01:53:02 +00:00
|
|
|
*/
|
2006-09-28 15:37:39 +00:00
|
|
|
if (max_change < 2)
|
|
|
|
return it;
|
|
|
|
return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
|
2006-09-27 01:53:02 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_name(FILE *file,
|
|
|
|
const char *prefix, const char *name, int len,
|
2006-09-27 01:59:41 +00:00
|
|
|
const char *reset, const char *set)
|
2006-09-27 01:53:02 +00:00
|
|
|
{
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, " %s%s%-*s%s |", set, prefix, len, name, reset);
|
2006-09-27 01:53:02 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_graph(FILE *file, char ch, int cnt, const char *set, const char *reset)
|
2006-09-27 01:53:02 +00:00
|
|
|
{
|
|
|
|
if (cnt <= 0)
|
|
|
|
return;
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "%s", set);
|
2006-09-27 01:53:02 +00:00
|
|
|
while (cnt--)
|
2008-03-10 02:43:39 +00:00
|
|
|
putc(ch, file);
|
|
|
|
fprintf(file, "%s", reset);
|
2006-09-27 01:53:02 +00:00
|
|
|
}
|
|
|
|
|
2007-12-12 07:46:30 +00:00
|
|
|
static void fill_print_name(struct diffstat_file *file)
|
|
|
|
{
|
|
|
|
char *pname;
|
|
|
|
|
|
|
|
if (file->print_name)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!file->is_renamed) {
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2007-12-12 07:46:30 +00: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;
|
|
|
|
}
|
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
static void show_stats(struct diffstat_t* data, struct diff_options *options)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int i, len, add, del, total, adds = 0, dels = 0;
|
2006-09-27 01:53:02 +00:00
|
|
|
int max_change = 0, max_len = 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
int total_files = data->nr;
|
2006-09-27 01:53:02 +00:00
|
|
|
int width, name_width;
|
2006-09-27 01:59:41 +00:00
|
|
|
const char *reset, *set, *add_c, *del_c;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
width = options->stat_width ? options->stat_width : 80;
|
|
|
|
name_width = options->stat_name_width ? options->stat_name_width : 50;
|
|
|
|
|
|
|
|
/* Sanity: give at least 5 columns to the graph,
|
|
|
|
* but leave at least 10 columns for the name.
|
|
|
|
*/
|
2008-06-27 00:18:48 +00:00
|
|
|
if (width < 25)
|
|
|
|
width = 25;
|
|
|
|
if (name_width < 10)
|
|
|
|
name_width = 10;
|
|
|
|
else if (width < name_width + 15)
|
|
|
|
name_width = width - 15;
|
2006-09-27 01:53:02 +00:00
|
|
|
|
|
|
|
/* Find the longest filename and max number of changes */
|
2007-11-10 19:05:14 +00:00
|
|
|
reset = diff_get_color_opt(options, DIFF_RESET);
|
|
|
|
set = diff_get_color_opt(options, DIFF_PLAIN);
|
|
|
|
add_c = diff_get_color_opt(options, DIFF_FILE_NEW);
|
|
|
|
del_c = diff_get_color_opt(options, DIFF_FILE_OLD);
|
2006-09-27 01:59:41 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
for (i = 0; i < data->nr; i++) {
|
|
|
|
struct diffstat_file *file = data->files[i];
|
2006-09-27 01:53:02 +00:00
|
|
|
int change = file->added + file->deleted;
|
2007-12-12 07:46:30 +00:00
|
|
|
fill_print_name(file);
|
|
|
|
len = strlen(file->print_name);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (max_len < len)
|
|
|
|
max_len = len;
|
|
|
|
|
|
|
|
if (file->is_binary || file->is_unmerged)
|
|
|
|
continue;
|
2006-09-27 01:53:02 +00:00
|
|
|
if (max_change < change)
|
|
|
|
max_change = change;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
/* Compute the width of the graph part;
|
|
|
|
* 10 is for one blank at the beginning of the line plus
|
|
|
|
* " | count " between the name and the graph.
|
|
|
|
*
|
|
|
|
* From here on, name_width is the width of the name area,
|
|
|
|
* and width is the width of the graph area.
|
|
|
|
*/
|
|
|
|
name_width = (name_width < max_len) ? name_width : max_len;
|
|
|
|
if (width < (name_width + 10) + max_change)
|
|
|
|
width = width - (name_width + 10);
|
|
|
|
else
|
|
|
|
width = max_change;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
for (i = 0; i < data->nr; i++) {
|
2006-06-24 17:20:32 +00:00
|
|
|
const char *prefix = "";
|
2007-12-12 07:46:30 +00:00
|
|
|
char *name = data->files[i]->print_name;
|
2006-04-22 06:57:45 +00:00
|
|
|
int added = data->files[i]->added;
|
|
|
|
int deleted = data->files[i]->deleted;
|
2006-09-27 01:53:02 +00:00
|
|
|
int name_len;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* "scale" the filename
|
|
|
|
*/
|
2006-09-27 01:53:02 +00:00
|
|
|
len = name_width;
|
|
|
|
name_len = strlen(name);
|
|
|
|
if (name_width < name_len) {
|
2006-04-22 06:57:45 +00:00
|
|
|
char *slash;
|
|
|
|
prefix = "...";
|
2006-09-27 01:53:02 +00:00
|
|
|
len -= 3;
|
|
|
|
name += name_len - len;
|
2006-04-22 06:57:45 +00:00
|
|
|
slash = strchr(name, '/');
|
|
|
|
if (slash)
|
|
|
|
name = slash;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (data->files[i]->is_binary) {
|
2008-03-10 02:43:39 +00:00
|
|
|
show_name(options->file, prefix, name, len, reset, set);
|
|
|
|
fprintf(options->file, " Bin ");
|
|
|
|
fprintf(options->file, "%s%d%s", del_c, deleted, reset);
|
|
|
|
fprintf(options->file, " -> ");
|
|
|
|
fprintf(options->file, "%s%d%s", add_c, added, reset);
|
|
|
|
fprintf(options->file, " bytes");
|
|
|
|
fprintf(options->file, "\n");
|
2007-12-12 07:46:30 +00:00
|
|
|
continue;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else if (data->files[i]->is_unmerged) {
|
2008-03-10 02:43:39 +00:00
|
|
|
show_name(options->file, prefix, name, len, reset, set);
|
|
|
|
fprintf(options->file, " Unmerged\n");
|
2007-12-12 07:46:30 +00:00
|
|
|
continue;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else if (!data->files[i]->is_renamed &&
|
|
|
|
(added + deleted == 0)) {
|
|
|
|
total_files--;
|
2007-12-12 07:46:30 +00:00
|
|
|
continue;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
/*
|
|
|
|
* scale the add/delete
|
|
|
|
*/
|
2006-04-22 06:57:45 +00:00
|
|
|
add = added;
|
|
|
|
del = deleted;
|
|
|
|
total = add + del;
|
|
|
|
adds += add;
|
|
|
|
dels += del;
|
|
|
|
|
2006-09-27 01:53:02 +00:00
|
|
|
if (width <= max_change) {
|
|
|
|
add = scale_linear(add, width, max_change);
|
2006-09-28 15:37:39 +00:00
|
|
|
del = scale_linear(del, width, max_change);
|
|
|
|
total = add + del;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2008-03-10 02:43:39 +00:00
|
|
|
show_name(options->file, prefix, name, len, reset, set);
|
2008-06-14 07:27:45 +00:00
|
|
|
fprintf(options->file, "%5d%s", added + deleted,
|
|
|
|
added + deleted ? " " : "");
|
2008-03-10 02:43:39 +00:00
|
|
|
show_graph(options->file, '+', add, add_c, reset);
|
|
|
|
show_graph(options->file, '-', del, del_c, reset);
|
|
|
|
fprintf(options->file, "\n");
|
|
|
|
}
|
|
|
|
fprintf(options->file,
|
|
|
|
"%s %d files changed, %d insertions(+), %d deletions(-)%s\n",
|
2006-09-27 01:59:41 +00:00
|
|
|
set, total_files, adds, dels, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_shortstats(struct diffstat_t* data, struct diff_options *options)
|
2006-12-15 04:15:44 +00:00
|
|
|
{
|
|
|
|
int i, adds = 0, dels = 0, total_files = data->nr;
|
|
|
|
|
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < data->nr; i++) {
|
|
|
|
if (!data->files[i]->is_binary &&
|
|
|
|
!data->files[i]->is_unmerged) {
|
|
|
|
int added = data->files[i]->added;
|
|
|
|
int deleted= data->files[i]->deleted;
|
|
|
|
if (!data->files[i]->is_renamed &&
|
|
|
|
(added + deleted == 0)) {
|
|
|
|
total_files--;
|
|
|
|
} else {
|
|
|
|
adds += added;
|
|
|
|
dels += deleted;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(options->file, " %d files changed, %d insertions(+), %d deletions(-)\n",
|
2006-12-15 04:15:44 +00:00
|
|
|
total_files, adds, dels);
|
|
|
|
}
|
|
|
|
|
2006-10-12 10:01:00 +00:00
|
|
|
static void show_numstat(struct diffstat_t* data, struct diff_options *options)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2007-12-12 07:46:30 +00:00
|
|
|
if (data->nr == 0)
|
|
|
|
return;
|
|
|
|
|
2006-10-12 10:01:00 +00:00
|
|
|
for (i = 0; i < data->nr; i++) {
|
|
|
|
struct diffstat_file *file = data->files[i];
|
|
|
|
|
2006-12-10 21:50:59 +00:00
|
|
|
if (file->is_binary)
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(options->file, "-\t-\t");
|
2006-12-10 21:50:59 +00:00
|
|
|
else
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(options->file,
|
|
|
|
"%d\t%d\t", file->added, file->deleted);
|
2007-12-12 07:46:30 +00:00
|
|
|
if (options->line_termination) {
|
|
|
|
fill_print_name(file);
|
|
|
|
if (!file->is_renamed)
|
2008-03-10 02:43:39 +00:00
|
|
|
write_name_quoted(file->name, options->file,
|
2007-12-12 07:46:30 +00:00
|
|
|
options->line_termination);
|
|
|
|
else {
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(file->print_name, options->file);
|
|
|
|
putc(options->line_termination, options->file);
|
2007-12-12 07:46:30 +00: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-19 22:42:15 +00:00
|
|
|
} else {
|
2007-12-12 07:46:30 +00:00
|
|
|
if (file->is_renamed) {
|
2008-03-10 02:43:39 +00:00
|
|
|
putc('\0', options->file);
|
|
|
|
write_name_quoted(file->from_name, options->file, '\0');
|
2007-12-12 07:46:30 +00:00
|
|
|
}
|
2008-03-10 02:43:39 +00: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-19 22:42:15 +00:00
|
|
|
}
|
2006-10-12 10:01:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-13 01:06:58 +00: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-12 21:26:31 +00:00
|
|
|
};
|
|
|
|
|
2008-02-13 01:06:58 +00:00
|
|
|
struct dirstat_dir {
|
|
|
|
struct dirstat_file *files;
|
|
|
|
int alloc, nr, percent, cumulative;
|
|
|
|
};
|
|
|
|
|
|
|
|
static long gather_dirstat(FILE *file, 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-12 21:26:31 +00:00
|
|
|
{
|
|
|
|
unsigned long this_dir = 0;
|
|
|
|
unsigned int sources = 0;
|
|
|
|
|
|
|
|
while (dir->nr) {
|
2008-02-13 01:06:58 +00: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-12 21:26:31 +00: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;
|
2008-03-10 02:43:39 +00:00
|
|
|
this = gather_dirstat(file, 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-12 21:26:31 +00:00
|
|
|
sources++;
|
|
|
|
} else {
|
2008-02-13 01:06:58 +00: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-12 21:26:31 +00: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) {
|
|
|
|
int permille = this_dir * 1000 / changed;
|
|
|
|
if (permille) {
|
|
|
|
int percent = permille / 10;
|
|
|
|
if (percent >= dir->percent) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "%4d.%01d%% %.*s\n", percent, 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-12 21:26:31 +00:00
|
|
|
if (!dir->cumulative)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return this_dir;
|
|
|
|
}
|
|
|
|
|
2008-08-28 23:19:08 +00: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 01:06:58 +00: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-12 21:26:31 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long changed;
|
2008-02-13 01:06:58 +00:00
|
|
|
struct dirstat_dir dir;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
|
|
|
|
dir.files = NULL;
|
|
|
|
dir.alloc = 0;
|
|
|
|
dir.nr = 0;
|
|
|
|
dir.percent = options->dirstat_percent;
|
2008-09-03 00:28:59 +00: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-12 21:26:31 +00:00
|
|
|
|
|
|
|
changed = 0;
|
2008-02-13 01:06:58 +00:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
const char *name;
|
|
|
|
unsigned long copied, added, damage;
|
|
|
|
|
|
|
|
name = p->one->path ? p->one->path : p->two->path;
|
|
|
|
|
|
|
|
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 01:37:15 +00:00
|
|
|
continue;
|
2008-02-13 01:06:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Original minus copied is the removed material,
|
|
|
|
* added is the new material. They are both damages
|
2008-09-05 19:27:35 +00:00
|
|
|
* made to the preimage. In --dirstat-by-file mode, count
|
|
|
|
* damaged files, not damaged lines. This is done by
|
|
|
|
* counting only a single damaged line per file.
|
2008-02-13 01:06:58 +00:00
|
|
|
*/
|
|
|
|
damage = (p->one->size - copied) + added;
|
2008-09-05 19:27:35 +00:00
|
|
|
if (DIFF_OPT_TST(options, DIRSTAT_BY_FILE) && damage > 0)
|
|
|
|
damage = 1;
|
2008-02-13 01:06:58 +00: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-12 21:26:31 +00: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-28 23:19:08 +00:00
|
|
|
qsort(dir.files, dir.nr, sizeof(dir.files[0]), dirstat_compare);
|
2008-03-10 02:43:39 +00:00
|
|
|
gather_dirstat(options->file, &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-12 21:26:31 +00:00
|
|
|
}
|
|
|
|
|
2007-12-12 07:46:30 +00: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-20 21:43:13 +00:00
|
|
|
struct checkdiff_t {
|
|
|
|
const char *filename;
|
2008-06-26 22:36:34 +00:00
|
|
|
int lineno;
|
|
|
|
struct diff_options *o;
|
2007-12-06 08:14:14 +00:00
|
|
|
unsigned ws_rule;
|
2007-12-13 20:24:52 +00:00
|
|
|
unsigned status;
|
2008-06-26 22:36:59 +00:00
|
|
|
int trailing_blanks_start;
|
2006-05-20 21:43:13 +00:00
|
|
|
};
|
|
|
|
|
2008-06-26 22:37:21 +00:00
|
|
|
static int is_conflict_marker(const char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
char firstchar;
|
|
|
|
int cnt;
|
|
|
|
|
|
|
|
if (len < 8)
|
|
|
|
return 0;
|
|
|
|
firstchar = line[0];
|
|
|
|
switch (firstchar) {
|
|
|
|
case '=': case '>': case '<':
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
for (cnt = 1; cnt < 7; cnt++)
|
|
|
|
if (line[cnt] != firstchar)
|
|
|
|
return 0;
|
|
|
|
/* line[0] thru line[6] are same as firstchar */
|
|
|
|
if (firstchar == '=') {
|
|
|
|
/* divider between ours and theirs? */
|
|
|
|
if (len != 8 || line[7] != '\n')
|
|
|
|
return 0;
|
|
|
|
} else if (len < 8 || !isspace(line[7])) {
|
|
|
|
/* not divider before ours nor after theirs */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-05-20 21:43:13 +00:00
|
|
|
static void checkdiff_consume(void *priv, char *line, unsigned long len)
|
|
|
|
{
|
|
|
|
struct checkdiff_t *data = priv;
|
2008-06-26 22:36:34 +00:00
|
|
|
int color_diff = DIFF_OPT_TST(data->o, COLOR_DIFF);
|
|
|
|
const char *ws = diff_get_color(color_diff, DIFF_WHITESPACE);
|
|
|
|
const char *reset = diff_get_color(color_diff, DIFF_RESET);
|
|
|
|
const char *set = diff_get_color(color_diff, DIFF_FILE_NEW);
|
2007-12-13 13:32:29 +00:00
|
|
|
char *err;
|
2006-05-20 21:43:13 +00:00
|
|
|
|
|
|
|
if (line[0] == '+') {
|
2008-06-26 20:16:33 +00:00
|
|
|
unsigned bad;
|
2008-02-16 04:30:05 +00:00
|
|
|
data->lineno++;
|
2008-06-26 22:36:59 +00:00
|
|
|
if (!ws_blank_line(line + 1, len - 1, data->ws_rule))
|
|
|
|
data->trailing_blanks_start = 0;
|
|
|
|
else if (!data->trailing_blanks_start)
|
|
|
|
data->trailing_blanks_start = data->lineno;
|
2008-06-26 22:37:21 +00:00
|
|
|
if (is_conflict_marker(line + 1, len - 1)) {
|
|
|
|
data->status |= 1;
|
|
|
|
fprintf(data->o->file,
|
|
|
|
"%s:%d: leftover conflict marker\n",
|
|
|
|
data->filename, data->lineno);
|
|
|
|
}
|
2008-06-26 22:35:21 +00:00
|
|
|
bad = ws_check(line + 1, len - 1, data->ws_rule);
|
2008-06-26 20:16:33 +00:00
|
|
|
if (!bad)
|
2007-12-13 13:32:29 +00:00
|
|
|
return;
|
2008-06-26 20:16:33 +00:00
|
|
|
data->status |= bad;
|
|
|
|
err = whitespace_error_string(bad);
|
2008-06-26 22:36:34 +00:00
|
|
|
fprintf(data->o->file, "%s:%d: %s.\n",
|
|
|
|
data->filename, data->lineno, err);
|
2007-12-13 13:32:29 +00:00
|
|
|
free(err);
|
2008-06-26 22:36:34 +00:00
|
|
|
emit_line(data->o->file, set, reset, line, 1);
|
2008-06-26 22:35:21 +00:00
|
|
|
ws_check_emit(line + 1, len - 1, data->ws_rule,
|
2008-06-26 22:36:34 +00:00
|
|
|
data->o->file, set, reset, ws);
|
2008-06-26 22:36:59 +00:00
|
|
|
} else if (line[0] == ' ') {
|
2006-05-20 21:43:13 +00:00
|
|
|
data->lineno++;
|
2008-06-26 22:36:59 +00:00
|
|
|
data->trailing_blanks_start = 0;
|
|
|
|
} else if (line[0] == '@') {
|
2006-05-20 21:43:13 +00:00
|
|
|
char *plus = strchr(line, '+');
|
|
|
|
if (plus)
|
2008-02-16 04:30:05 +00:00
|
|
|
data->lineno = strtol(plus, NULL, 10) - 1;
|
2006-05-20 21:43:13 +00:00
|
|
|
else
|
|
|
|
die("invalid diff");
|
2008-06-26 22:36:59 +00:00
|
|
|
data->trailing_blanks_start = 0;
|
2006-05-20 21:43:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
{
|
2006-05-05 09:41:53 +00:00
|
|
|
int bound;
|
|
|
|
unsigned char *deflated;
|
|
|
|
z_stream stream;
|
|
|
|
|
|
|
|
memset(&stream, 0, sizeof(stream));
|
2006-07-03 20:11:47 +00:00
|
|
|
deflateInit(&stream, zlib_compression_level);
|
2006-05-05 09:41:53 +00:00
|
|
|
bound = deflateBound(&stream, size);
|
|
|
|
deflated = xmalloc(bound);
|
|
|
|
stream.next_out = deflated;
|
|
|
|
stream.avail_out = bound;
|
|
|
|
|
|
|
|
stream.next_in = (unsigned char *)data;
|
|
|
|
stream.avail_in = size;
|
|
|
|
while (deflate(&stream, Z_FINISH) == Z_OK)
|
|
|
|
; /* nothing */
|
|
|
|
deflateEnd(&stream);
|
|
|
|
*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-04 23:51:44 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void emit_binary_diff_body(FILE *file, mmfile_t *one, mmfile_t *two)
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04 23:51:44 +00:00
|
|
|
{
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
*/
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-05-05 09:41:53 +00:00
|
|
|
if (delta && delta_size < deflate_size) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "delta %lu\n", orig_size);
|
2006-05-05 09:41:53 +00:00
|
|
|
free(deflated);
|
|
|
|
data = delta;
|
|
|
|
data_size = delta_size;
|
|
|
|
}
|
|
|
|
else {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "literal %lu\n", two->size);
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
char line[70];
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00: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 15:18:09 +00:00
|
|
|
cp = (char *) cp + bytes;
|
2008-03-10 02:43:39 +00: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-04 23:51:44 +00:00
|
|
|
}
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "\n");
|
2006-05-05 09:41:53 +00: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-04 23:51:44 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void emit_binary_diff(FILE *file, mmfile_t *one, mmfile_t *two)
|
2006-08-16 23:08:14 +00:00
|
|
|
{
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, "GIT binary patch\n");
|
|
|
|
emit_binary_diff_body(file, one, two);
|
|
|
|
emit_binary_diff_body(file, two, one);
|
2006-08-16 23:08:14 +00:00
|
|
|
}
|
|
|
|
|
2008-10-26 04:41:28 +00:00
|
|
|
static void diff_filespec_load_driver(struct diff_filespec *one)
|
2006-04-22 06:57:45 +00: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-05 21:43:36 +00:00
|
|
|
if (!one->driver)
|
|
|
|
one->driver = userdiff_find_by_path(one->path);
|
|
|
|
if (!one->driver)
|
|
|
|
one->driver = userdiff_find_by_name("default");
|
2007-07-06 07:18:54 +00: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-05 21:43:36 +00: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 07:18:54 +00:00
|
|
|
return one->is_binary;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2008-10-05 21:43:21 +00:00
|
|
|
static const struct userdiff_funcname *diff_funcname_pattern(struct diff_filespec *one)
|
2007-07-06 07:45:10 +00: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-05 21:43:36 +00:00
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
return one->driver->funcname.pattern ? &one->driver->funcname : NULL;
|
2007-07-06 07:45:10 +00:00
|
|
|
}
|
|
|
|
|
2009-01-17 16:29:48 +00:00
|
|
|
static const char *userdiff_word_regex(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
return one->driver->word_regex;
|
|
|
|
}
|
|
|
|
|
2008-08-19 03:08:09 +00: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;
|
|
|
|
}
|
|
|
|
|
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 04:44:53 +00:00
|
|
|
static const char *get_textconv(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (!DIFF_FILE_VALID(one))
|
|
|
|
return NULL;
|
2008-10-26 04:46:21 +00:00
|
|
|
if (!S_ISREG(one->mode))
|
|
|
|
return NULL;
|
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 04:44:53 +00:00
|
|
|
diff_filespec_load_driver(one);
|
|
|
|
return one->driver->textconv;
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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,
|
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-04 23:51:44 +00:00
|
|
|
struct diff_options *o,
|
2006-04-22 06:57:45 +00:00
|
|
|
int complete_rewrite)
|
|
|
|
{
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
const char *lbl[2];
|
|
|
|
char *a_one, *b_two;
|
2007-11-10 19:05:14 +00:00
|
|
|
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
|
|
|
|
const char *reset = diff_get_color_opt(o, DIFF_RESET);
|
2008-08-19 03:08:09 +00:00
|
|
|
const char *a_prefix, *b_prefix;
|
2008-10-26 04:45:55 +00:00
|
|
|
const char *textconv_one = NULL, *textconv_two = NULL;
|
2008-08-19 03:08:09 +00:00
|
|
|
|
2008-12-09 08:13:21 +00:00
|
|
|
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
|
|
|
|
textconv_one = get_textconv(one);
|
|
|
|
textconv_two = get_textconv(two);
|
|
|
|
}
|
|
|
|
|
2008-08-19 03:08:09 +00: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 06:57:45 +00: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-05 19:35:15 +00: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 03:08:09 +00:00
|
|
|
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
|
|
|
|
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
|
2006-04-22 06:57:45 +00:00
|
|
|
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
|
|
|
|
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (lbl[0][0] == '/') {
|
|
|
|
/* /dev/null */
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%snew file mode %06o%s\n", set, two->mode, reset);
|
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-22 20:53:31 +00:00
|
|
|
if (xfrm_msg && xfrm_msg[0])
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%s%s%s\n", set, xfrm_msg, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else if (lbl[1][0] == '/') {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%sdeleted file mode %06o%s\n", set, one->mode, reset);
|
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-22 20:53:31 +00:00
|
|
|
if (xfrm_msg && xfrm_msg[0])
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%s%s%s\n", set, xfrm_msg, reset);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (one->mode != two->mode) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%sold mode %06o%s\n", set, one->mode, reset);
|
|
|
|
fprintf(o->file, "%snew mode %06o%s\n", set, two->mode, reset);
|
2006-06-13 16:45:44 +00:00
|
|
|
}
|
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-22 20:53:31 +00:00
|
|
|
if (xfrm_msg && xfrm_msg[0])
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "%s%s%s\n", set, xfrm_msg, reset);
|
2006-04-22 06:57:45 +00: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 08:12:28 +00:00
|
|
|
if (complete_rewrite &&
|
2008-12-09 08:13:21 +00:00
|
|
|
(textconv_one || !diff_filespec_is_binary(one)) &&
|
|
|
|
(textconv_two || !diff_filespec_is_binary(two))) {
|
|
|
|
emit_rewrite_diff(name_a, name_b, one, two,
|
|
|
|
textconv_one, textconv_two, o);
|
2007-02-25 22:34:54 +00:00
|
|
|
o->found_changes = 1;
|
2006-04-22 06:57:45 +00:00
|
|
|
goto free_ab_and_return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (!DIFF_OPT_TST(o, TEXT) &&
|
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 04:44:53 +00:00
|
|
|
( (diff_filespec_is_binary(one) && !textconv_one) ||
|
|
|
|
(diff_filespec_is_binary(two) && !textconv_two) )) {
|
2006-05-05 09:41:53 +00:00
|
|
|
/* Quite common confusing case */
|
|
|
|
if (mf1.size == mf2.size &&
|
|
|
|
!memcmp(mf1.ptr, mf2.ptr, mf1.size))
|
|
|
|
goto free_ab_and_return;
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(o, BINARY))
|
2008-03-10 02:43:39 +00:00
|
|
|
emit_binary_diff(o->file, &mf1, &mf2);
|
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-04 23:51:44 +00:00
|
|
|
else
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "Binary files %s and %s differ\n",
|
|
|
|
lbl[0], lbl[1]);
|
2007-02-25 22:34:54 +00:00
|
|
|
o->found_changes = 1;
|
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-04 23:51:44 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
else {
|
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
const char *diffopts = getenv("GIT_DIFF_OPTS");
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
xdemitcb_t ecb;
|
|
|
|
struct emit_callback ecbdata;
|
2008-10-05 21:43:21 +00:00
|
|
|
const struct userdiff_funcname *pe;
|
2007-07-06 07:45:10 +00: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 04:44:53 +00:00
|
|
|
if (textconv_one) {
|
|
|
|
size_t size;
|
|
|
|
mf1.ptr = run_textconv(textconv_one, one, &size);
|
|
|
|
if (!mf1.ptr)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
mf1.size = size;
|
|
|
|
}
|
|
|
|
if (textconv_two) {
|
|
|
|
size_t size;
|
|
|
|
mf2.ptr = run_textconv(textconv_two, two, &size);
|
|
|
|
if (!mf2.ptr)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
mf2.size = size;
|
|
|
|
}
|
|
|
|
|
2008-09-18 22:40:48 +00:00
|
|
|
pe = diff_funcname_pattern(one);
|
|
|
|
if (!pe)
|
|
|
|
pe = diff_funcname_pattern(two);
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2008-10-25 13:30:37 +00:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-04 18:05:46 +00:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-13 16:45:44 +00:00
|
|
|
memset(&ecbdata, 0, sizeof(ecbdata));
|
2006-04-22 06:57:45 +00:00
|
|
|
ecbdata.label_path = lbl;
|
2007-11-10 19:05:14 +00:00
|
|
|
ecbdata.color_diff = DIFF_OPT_TST(o, COLOR_DIFF);
|
2007-02-25 22:34:54 +00:00
|
|
|
ecbdata.found_changesp = &o->found_changes;
|
2007-12-06 08:14:14 +00:00
|
|
|
ecbdata.ws_rule = whitespace_rule(name_b ? name_b : name_a);
|
2008-03-10 02:43:39 +00:00
|
|
|
ecbdata.file = o->file;
|
2006-06-14 15:40:23 +00:00
|
|
|
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
|
2006-05-13 20:23:48 +00:00
|
|
|
xecfg.ctxlen = o->context;
|
2008-12-28 18:45:32 +00:00
|
|
|
xecfg.interhunkctxlen = o->interhunkcontext;
|
2006-04-22 06:57:45 +00:00
|
|
|
xecfg.flags = XDL_EMIT_FUNCNAMES;
|
2008-09-18 22:40:48 +00:00
|
|
|
if (pe)
|
2008-09-18 22:42:48 +00:00
|
|
|
xdiff_set_find_func(&xecfg, pe->pattern, pe->cflags);
|
2006-04-22 06:57:45 +00: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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(diffopts, "--unified="))
|
2006-04-22 06:57:45 +00: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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(diffopts, "-u"))
|
2006-04-22 06:57:45 +00:00
|
|
|
xecfg.ctxlen = strtoul(diffopts + 2, NULL, 10);
|
2008-03-10 02:43:39 +00:00
|
|
|
if (DIFF_OPT_TST(o, COLOR_DIFF_WORDS)) {
|
2006-07-28 21:56:15 +00:00
|
|
|
ecbdata.diff_words =
|
|
|
|
xcalloc(1, sizeof(struct diff_words_data));
|
2008-03-10 02:43:39 +00:00
|
|
|
ecbdata.diff_words->file = o->file;
|
2009-01-17 16:29:48 +00:00
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = userdiff_word_regex(one);
|
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = userdiff_word_regex(two);
|
2009-01-21 03:46:57 +00:00
|
|
|
if (!o->word_regex)
|
|
|
|
o->word_regex = diff_word_regex_cfg;
|
2009-01-17 16:29:45 +00:00
|
|
|
if (o->word_regex) {
|
|
|
|
ecbdata.diff_words->word_regex = (regex_t *)
|
|
|
|
xmalloc(sizeof(regex_t));
|
|
|
|
if (regcomp(ecbdata.diff_words->word_regex,
|
2009-01-17 16:29:46 +00:00
|
|
|
o->word_regex,
|
|
|
|
REG_EXTENDED | REG_NEWLINE))
|
2009-01-17 16:29:45 +00:00
|
|
|
die ("Invalid regular expression: %s",
|
|
|
|
o->word_regex);
|
|
|
|
}
|
2008-03-10 02:43:39 +00:00
|
|
|
}
|
2008-08-14 06:18:22 +00:00
|
|
|
xdi_diff_outf(&mf1, &mf2, fn_out_consume, &ecbdata,
|
|
|
|
&xpp, &xecfg, &ecb);
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(o, COLOR_DIFF_WORDS))
|
2006-07-28 21:56:15 +00: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 04:44:53 +00:00
|
|
|
if (textconv_one)
|
|
|
|
free(mf1.ptr);
|
|
|
|
if (textconv_two)
|
|
|
|
free(mf2.ptr);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
free_ab_and_return:
|
2007-05-03 20:05:48 +00:00
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2006-04-22 06:57:45 +00: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 06:40:09 +00:00
|
|
|
struct diffstat_t *diffstat,
|
2006-06-14 15:40:23 +00:00
|
|
|
struct diff_options *o,
|
2006-04-26 06:40:09 +00:00
|
|
|
int complete_rewrite)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
struct diffstat_file *data;
|
|
|
|
|
|
|
|
data = diffstat_add(diffstat, name_a, name_b);
|
|
|
|
|
|
|
|
if (!one || !two) {
|
|
|
|
data->is_unmerged = 1;
|
|
|
|
return;
|
|
|
|
}
|
2006-04-26 06:40:09 +00:00
|
|
|
if (complete_rewrite) {
|
|
|
|
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);
|
2007-05-03 20:05:48 +00:00
|
|
|
goto free_and_return;
|
2006-04-26 06:40:09 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
|
2007-07-06 07:18:54 +00:00
|
|
|
if (diff_filespec_is_binary(one) || diff_filespec_is_binary(two)) {
|
2006-04-22 06:57:45 +00:00
|
|
|
data->is_binary = 1;
|
2007-04-04 13:14:14 +00:00
|
|
|
data->added = mf2.size;
|
|
|
|
data->deleted = mf1.size;
|
|
|
|
} else {
|
2006-04-22 06:57:45 +00:00
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
xdemitcb_t ecb;
|
|
|
|
|
2008-10-25 13:30:37 +00:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-04 18:05:46 +00:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-14 15:40:23 +00:00
|
|
|
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
|
2008-08-14 06:18:22 +00:00
|
|
|
xdi_diff_outf(&mf1, &mf2, diffstat_consume, diffstat,
|
|
|
|
&xpp, &xecfg, &ecb);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2007-05-03 20:05:48 +00:00
|
|
|
|
|
|
|
free_and_return:
|
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2006-05-20 21:43:13 +00: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-12 22:26:02 +00:00
|
|
|
const char *attr_path,
|
2008-06-26 22:34:54 +00:00
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
|
|
|
struct diff_options *o)
|
2006-05-20 21:43:13 +00: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-26 22:36:34 +00: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-12 22:26:02 +00:00
|
|
|
data.ws_rule = whitespace_rule(attr_path);
|
2006-05-20 21:43:13 +00:00
|
|
|
|
|
|
|
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
|
|
|
|
die("unable to read files to diff");
|
|
|
|
|
2008-06-26 22:34:54 +00: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 07:18:54 +00:00
|
|
|
if (diff_filespec_is_binary(two))
|
2007-05-03 20:05:48 +00:00
|
|
|
goto free_and_return;
|
2006-05-20 21:43:13 +00:00
|
|
|
else {
|
|
|
|
/* Crazy xdl interfaces.. */
|
|
|
|
xpparam_t xpp;
|
|
|
|
xdemitconf_t xecfg;
|
|
|
|
xdemitcb_t ecb;
|
|
|
|
|
2008-10-25 13:30:37 +00:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-04 18:05:46 +00:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2008-08-20 18:47:55 +00:00
|
|
|
xecfg.ctxlen = 1; /* at least one context line */
|
2006-05-20 21:43:13 +00:00
|
|
|
xpp.flags = XDF_NEED_MINIMAL;
|
2008-08-14 06:18:22 +00:00
|
|
|
xdi_diff_outf(&mf1, &mf2, checkdiff_consume, &data,
|
|
|
|
&xpp, &xecfg, &ecb);
|
2008-06-26 22:36:59 +00:00
|
|
|
|
2008-08-12 05:15:28 +00:00
|
|
|
if ((data.ws_rule & WS_TRAILING_SPACE) &&
|
|
|
|
data.trailing_blanks_start) {
|
2008-06-26 22:36:59 +00:00
|
|
|
fprintf(o->file, "%s:%d: ends with blank lines.\n",
|
|
|
|
data.filename, data.trailing_blanks_start);
|
|
|
|
data.status = 1; /* report errors */
|
|
|
|
}
|
2006-05-20 21:43:13 +00:00
|
|
|
}
|
2007-05-03 20:05:48 +00:00
|
|
|
free_and_return:
|
|
|
|
diff_free_filespec_data(one);
|
|
|
|
diff_free_filespec_data(two);
|
2007-12-13 20:24:52 +00:00
|
|
|
if (data.status)
|
|
|
|
DIFF_OPT_SET(o, CHECK_FAILED);
|
2006-05-20 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-25 18:19:10 +00: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-05 21:43:36 +00:00
|
|
|
spec->is_binary = -1;
|
2006-04-22 06:57:45 +00:00
|
|
|
return spec;
|
|
|
|
}
|
|
|
|
|
2007-10-25 18:19:10 +00:00
|
|
|
void free_filespec(struct diff_filespec *spec)
|
|
|
|
{
|
|
|
|
if (!--spec->count) {
|
|
|
|
diff_free_filespec_data(spec);
|
|
|
|
free(spec);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
void fill_filespec(struct diff_filespec *spec, const unsigned char *sha1,
|
|
|
|
unsigned short mode)
|
|
|
|
{
|
|
|
|
if (mode) {
|
|
|
|
spec->mode = canon_mode(mode);
|
2006-08-23 06:49:00 +00:00
|
|
|
hashcpy(spec->sha1, sha1);
|
2006-08-15 20:37:19 +00:00
|
|
|
spec->sha1_valid = !is_null_sha1(sha1);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2007-05-25 22:37:40 +00:00
|
|
|
* Given a name and sha1 pair, if the index tells us the file in
|
2006-04-22 06:57:45 +00: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 11:15:57 +00:00
|
|
|
static int reuse_worktree_file(const char *name, const unsigned char *sha1, int want_file)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
struct cache_entry *ce;
|
|
|
|
struct stat st;
|
|
|
|
int pos, len;
|
|
|
|
|
|
|
|
/* We do not read the cache ourselves here, because the
|
|
|
|
* 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 11:15:57 +00: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.
|
|
|
|
*/
|
2006-12-20 02:26:48 +00:00
|
|
|
if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
|
2006-12-14 11:15:57 +00:00
|
|
|
return 0;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
len = strlen(name);
|
|
|
|
pos = cache_name_pos(name, len);
|
|
|
|
if (pos < 0)
|
|
|
|
return 0;
|
|
|
|
ce = active_cache[pos];
|
2008-01-19 07:45:24 +00: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 06:57:45 +00:00
|
|
|
return 0;
|
2008-01-19 07:45:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If ce matches the file in the work tree, we can reuse it.
|
2006-04-22 06:57:45 +00:00
|
|
|
*/
|
2008-01-19 07:45:24 +00:00
|
|
|
if (ce_uptodate(ce) ||
|
|
|
|
(!lstat(name, &st) && !ce_match_stat(ce, &st, 0)))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2007-03-04 08:17:27 +00:00
|
|
|
static int populate_from_stdin(struct diff_filespec *s)
|
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2007-10-21 09:23:49 +00:00
|
|
|
size_t size = 0;
|
2007-09-06 11:20:09 +00:00
|
|
|
|
2007-09-10 10:35:04 +00:00
|
|
|
if (strbuf_read(&buf, 0, 0) < 0)
|
2007-09-06 11:20:09 +00:00
|
|
|
return error("error while reading from stdin %s",
|
2007-03-04 08:17:27 +00:00
|
|
|
strerror(errno));
|
2007-09-06 11:20:09 +00:00
|
|
|
|
2007-03-04 08:17:27 +00:00
|
|
|
s->should_munmap = 0;
|
2007-10-21 09:23:49 +00:00
|
|
|
s->data = strbuf_detach(&buf, &size);
|
|
|
|
s->size = size;
|
2007-03-04 08:17:27 +00:00
|
|
|
s->should_free = 1;
|
|
|
|
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-15 18:14:28 +00:00
|
|
|
static int diff_populate_gitlink(struct diff_filespec *s, int size_only)
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
char *data = xmalloc(100);
|
|
|
|
len = snprintf(data, 100,
|
|
|
|
"Subproject commit %s\n", sha1_to_hex(s->sha1));
|
|
|
|
s->data = data;
|
|
|
|
s->size = len;
|
|
|
|
s->should_free = 1;
|
|
|
|
if (size_only) {
|
|
|
|
s->data = NULL;
|
|
|
|
free(data);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-03 20:05:48 +00: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-15 18:14:28 +00:00
|
|
|
|
2007-05-07 08:14:21 +00:00
|
|
|
if (size_only && 0 < s->size)
|
|
|
|
return 0;
|
|
|
|
|
2007-05-21 20:08:28 +00: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-15 18:14:28 +00:00
|
|
|
return diff_populate_gitlink(s, size_only);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (!s->sha1_valid ||
|
2006-12-14 11:15:57 +00:00
|
|
|
reuse_worktree_file(s->path, s->sha1, 0)) {
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2006-04-22 06:57:45 +00: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-13 19:07:23 +00:00
|
|
|
|
2007-03-04 08:17:27 +00:00
|
|
|
if (!strcmp(s->path, "-"))
|
|
|
|
return populate_from_stdin(s);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (lstat(s->path, &st) < 0) {
|
|
|
|
if (errno == ENOENT) {
|
|
|
|
err_empty:
|
|
|
|
err = -1;
|
|
|
|
empty:
|
2006-06-24 17:20:32 +00:00
|
|
|
s->data = (char *)"";
|
2006-04-22 06:57:45 +00:00
|
|
|
s->size = 0;
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
2007-03-07 01:44:37 +00:00
|
|
|
s->size = xsize_t(st.st_size);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (!s->size)
|
|
|
|
goto empty;
|
|
|
|
if (S_ISLNK(st.st_mode)) {
|
2008-12-17 18:26:13 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
if (strbuf_readlink(&sb, s->path, s->size))
|
2006-04-22 06:57:45 +00:00
|
|
|
goto err_empty;
|
2008-12-18 16:56:51 +00:00
|
|
|
s->size = sb.len;
|
|
|
|
s->data = strbuf_detach(&sb, NULL);
|
2008-12-17 18:26:13 +00:00
|
|
|
s->should_free = 1;
|
2006-04-22 06:57:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2008-12-17 18:26:13 +00:00
|
|
|
if (size_only)
|
|
|
|
return 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
fd = open(s->path, O_RDONLY);
|
|
|
|
if (fd < 0)
|
|
|
|
goto err_empty;
|
2006-12-24 05:47:23 +00:00
|
|
|
s->data = xmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
|
2006-04-22 06:57:45 +00: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-13 19:07:23 +00: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 11:25:58 +00:00
|
|
|
if (convert_to_git(s->path, s->data, s->size, &buf, safe_crlf)) {
|
2007-10-21 09:23:49 +00: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-13 19:07:23 +00:00
|
|
|
munmap(s->data, s->size);
|
|
|
|
s->should_munmap = 0;
|
2007-10-21 09:23:49 +00: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-13 19:07:23 +00:00
|
|
|
s->should_free = 1;
|
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else {
|
2007-02-26 19:55:59 +00:00
|
|
|
enum object_type type;
|
2007-05-07 08:14:21 +00:00
|
|
|
if (size_only)
|
2007-02-26 19:55:59 +00:00
|
|
|
type = sha1_object_info(s->sha1, &s->size);
|
2006-04-22 06:57:45 +00:00
|
|
|
else {
|
2007-02-26 19:55:59 +00:00
|
|
|
s->data = read_sha1_file(s->sha1, &type, &s->size);
|
2006-04-22 06:57:45 +00:00
|
|
|
s->should_free = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-03 04:01:03 +00:00
|
|
|
void diff_free_filespec_blob(struct diff_filespec *s)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
if (s->should_free)
|
|
|
|
free(s->data);
|
|
|
|
else if (s->should_munmap)
|
|
|
|
munmap(s->data, s->size);
|
2007-05-03 20:05:48 +00:00
|
|
|
|
|
|
|
if (s->should_free || s->should_munmap) {
|
|
|
|
s->should_free = s->should_munmap = 0;
|
|
|
|
s->data = NULL;
|
|
|
|
}
|
2007-09-25 19:29:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_free_filespec_data(struct diff_filespec *s)
|
|
|
|
{
|
2007-10-03 04:01:03 +00:00
|
|
|
diff_free_filespec_blob(s);
|
2006-04-22 06:57:45 +00:00
|
|
|
free(s->cnt_data);
|
|
|
|
s->cnt_data = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void prep_temp_blob(struct diff_tempfile *temp,
|
|
|
|
void *blob,
|
|
|
|
unsigned long size,
|
|
|
|
const unsigned char *sha1,
|
|
|
|
int mode)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
|
2007-05-20 13:35:46 +00:00
|
|
|
fd = git_mkstemp(temp->tmp_path, PATH_MAX, ".diff_XXXXXX");
|
2006-04-22 06:57:45 +00:00
|
|
|
if (fd < 0)
|
2007-07-26 04:34:53 +00:00
|
|
|
die("unable to create temp-file: %s", strerror(errno));
|
2007-01-08 15:58:23 +00:00
|
|
|
if (write_in_full(fd, blob, size) != size)
|
2006-04-22 06:57:45 +00:00
|
|
|
die("unable to write temp-file");
|
|
|
|
close(fd);
|
|
|
|
temp->name = temp->tmp_path;
|
|
|
|
strcpy(temp->hex, sha1_to_hex(sha1));
|
|
|
|
temp->hex[40] = 0;
|
|
|
|
sprintf(temp->mode, "%06o", 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 05:59:56 +00:00
|
|
|
static struct diff_tempfile *prepare_temp_file(const char *name,
|
|
|
|
struct diff_filespec *one)
|
2006-04-22 06:57:45 +00: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 05:59:56 +00:00
|
|
|
struct diff_tempfile *temp = claim_diff_tempfile();
|
|
|
|
|
2006-04-22 06:57:45 +00: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 05:59:56 +00:00
|
|
|
return temp;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!remove_tempfile_installed) {
|
|
|
|
atexit(remove_tempfile);
|
2009-01-22 06:03:08 +00: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 05:59:56 +00:00
|
|
|
remove_tempfile_installed = 1;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!one->sha1_valid ||
|
2006-12-14 11:15:57 +00:00
|
|
|
reuse_worktree_file(name, one->sha1, 1)) {
|
2006-04-22 06:57:45 +00:00
|
|
|
struct stat st;
|
|
|
|
if (lstat(name, &st) < 0) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
goto not_a_valid_file;
|
|
|
|
die("stat(%s): %s", name, strerror(errno));
|
|
|
|
}
|
|
|
|
if (S_ISLNK(st.st_mode)) {
|
|
|
|
int ret;
|
|
|
|
char buf[PATH_MAX + 1]; /* ought to be SYMLINK_MAX */
|
2008-12-17 18:31:36 +00:00
|
|
|
ret = readlink(name, buf, sizeof(buf));
|
2006-04-22 06:57:45 +00:00
|
|
|
if (ret < 0)
|
|
|
|
die("readlink(%s)", name);
|
2008-12-17 18:31:36 +00:00
|
|
|
if (ret == sizeof(buf))
|
|
|
|
die("symlink too long: %s", name);
|
|
|
|
prep_temp_blob(temp, buf, ret,
|
2006-04-22 06:57:45 +00:00
|
|
|
(one->sha1_valid ?
|
|
|
|
one->sha1 : null_sha1),
|
|
|
|
(one->sha1_valid ?
|
|
|
|
one->mode : S_IFLNK));
|
|
|
|
}
|
|
|
|
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 05:59:56 +00:00
|
|
|
return temp;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (diff_populate_filespec(one, 0))
|
|
|
|
die("cannot read data blob for %s", one->path);
|
|
|
|
prep_temp_blob(temp, one->data, one->size,
|
|
|
|
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 05:59:56 +00:00
|
|
|
return temp;
|
2006-04-22 06:57:45 +00: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 05:59:56 +00: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 06:57:45 +00: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 05:59:56 +00: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 06:57:45 +00:00
|
|
|
if (other) {
|
|
|
|
*arg++ = other;
|
|
|
|
*arg++ = xfrm_msg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
*arg++ = pgm;
|
|
|
|
*arg++ = name;
|
|
|
|
}
|
|
|
|
*arg = NULL;
|
2007-10-19 19:47:56 +00:00
|
|
|
fflush(NULL);
|
|
|
|
retval = run_command_v_opt(spawn_arg, 0);
|
2006-04-22 06:57:45 +00:00
|
|
|
remove_tempfile();
|
|
|
|
if (retval) {
|
|
|
|
fprintf(stderr, "external diff died, stopping at %s.\n", name);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-26 08:08:24 +00: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,
|
|
|
|
struct diff_filepair *p)
|
|
|
|
{
|
|
|
|
strbuf_init(msg, PATH_MAX * 2 + 300);
|
|
|
|
switch (p->status) {
|
|
|
|
case DIFF_STATUS_COPIED:
|
|
|
|
strbuf_addf(msg, "similarity index %d%%", similarity_index(p));
|
|
|
|
strbuf_addstr(msg, "\ncopy from ");
|
|
|
|
quote_c_style(name, msg, NULL, 0);
|
|
|
|
strbuf_addstr(msg, "\ncopy to ");
|
|
|
|
quote_c_style(other, msg, NULL, 0);
|
|
|
|
strbuf_addch(msg, '\n');
|
|
|
|
break;
|
|
|
|
case DIFF_STATUS_RENAMED:
|
|
|
|
strbuf_addf(msg, "similarity index %d%%", similarity_index(p));
|
|
|
|
strbuf_addstr(msg, "\nrename from ");
|
|
|
|
quote_c_style(name, msg, NULL, 0);
|
|
|
|
strbuf_addstr(msg, "\nrename to ");
|
|
|
|
quote_c_style(other, msg, NULL, 0);
|
|
|
|
strbuf_addch(msg, '\n');
|
|
|
|
break;
|
|
|
|
case DIFF_STATUS_MODIFIED:
|
|
|
|
if (p->score) {
|
|
|
|
strbuf_addf(msg, "dissimilarity index %d%%\n",
|
|
|
|
similarity_index(p));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* fallthru */
|
|
|
|
default:
|
|
|
|
/* nothing */
|
|
|
|
;
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
strbuf_addf(msg, "index %.*s..%.*s",
|
|
|
|
abbrev, sha1_to_hex(one->sha1),
|
|
|
|
abbrev, sha1_to_hex(two->sha1));
|
|
|
|
if (one->mode == two->mode)
|
|
|
|
strbuf_addf(msg, " %06o", one->mode);
|
|
|
|
strbuf_addch(msg, '\n');
|
|
|
|
}
|
|
|
|
if (msg->len)
|
|
|
|
strbuf_setlen(msg, msg->len - 1);
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
const char *attr_path,
|
2006-04-22 06:57:45 +00:00
|
|
|
struct diff_filespec *one,
|
|
|
|
struct diff_filespec *two,
|
2009-01-26 08:08:24 +00: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-04 23:51:44 +00:00
|
|
|
struct diff_options *o,
|
2009-01-26 08:08:24 +00:00
|
|
|
struct diff_filepair *p)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
2009-01-26 08:08:24 +00:00
|
|
|
const char *xfrm_msg = NULL;
|
|
|
|
int complete_rewrite = (p->status == DIFF_STATUS_MODIFIED) && p->score;
|
|
|
|
|
|
|
|
if (msg) {
|
|
|
|
fill_metainfo(msg, name, other, one, two, o, p);
|
|
|
|
xfrm_msg = msg->len ? msg->buf : NULL;
|
|
|
|
}
|
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (!DIFF_OPT_TST(o, ALLOW_EXTERNAL))
|
2007-04-23 00:52:55 +00:00
|
|
|
pgm = NULL;
|
|
|
|
else {
|
2008-10-05 21:43:21 +00:00
|
|
|
struct userdiff_driver *drv = userdiff_find_by_path(attr_path);
|
|
|
|
if (drv && drv->external)
|
|
|
|
pgm = drv->external;
|
2007-04-23 00:52:55 +00:00
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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,
|
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-04 23:51:44 +00:00
|
|
|
one, two, xfrm_msg, o, complete_rewrite);
|
2006-04-22 06:57:45 +00:00
|
|
|
else
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(o->file, "* Unmerged path %s\n", name);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void diff_fill_sha1_info(struct diff_filespec *one)
|
|
|
|
{
|
|
|
|
if (DIFF_FILE_VALID(one)) {
|
|
|
|
if (!one->sha1_valid) {
|
|
|
|
struct stat st;
|
2007-02-25 22:36:10 +00:00
|
|
|
if (!strcmp(one->path, "-")) {
|
|
|
|
hashcpy(one->sha1, null_sha1);
|
|
|
|
return;
|
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
if (lstat(one->path, &st) < 0)
|
|
|
|
die("stat %s", one->path);
|
|
|
|
if (index_path(one->sha1, one->path, &st, 0))
|
2009-01-04 18:38:41 +00:00
|
|
|
die("cannot hash %s", one->path);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2006-08-23 06:49:00 +00:00
|
|
|
hashclr(one->sha1);
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00: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 */
|
|
|
|
if (*namep && **namep != '/')
|
|
|
|
*namep += prefix_length;
|
|
|
|
if (*otherp && **otherp != '/')
|
|
|
|
*otherp += prefix_length;
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
struct strbuf msg;
|
|
|
|
struct diff_filespec *one = p->one;
|
|
|
|
struct diff_filespec *two = p->two;
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00: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-19 22:42:15 +00: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-12 22:26:02 +00: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 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
run_diff_cmd(pgm, name, NULL, attr_path,
|
2009-01-26 08:08:24 +00:00
|
|
|
NULL, NULL, NULL, o, p);
|
2006-04-22 06:57:45 +00: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 08:08:24 +00:00
|
|
|
/*
|
|
|
|
* a filepair that changes between file and symlink
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
run_diff_cmd(NULL, name, other, attr_path,
|
2009-01-26 08:08:24 +00:00
|
|
|
one, null, &msg, o, p);
|
2006-04-22 06:57:45 +00:00
|
|
|
free(null);
|
2009-01-26 08:08:24 +00:00
|
|
|
strbuf_release(&msg);
|
|
|
|
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
run_diff_cmd(NULL, name, other, attr_path,
|
2009-01-26 08:08:24 +00:00
|
|
|
null, two, &msg, o, p);
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
run_diff_cmd(pgm, name, other, attr_path,
|
2009-01-26 08:08:24 +00:00
|
|
|
one, two, &msg, o, p);
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
strbuf_release(&msg);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void run_diffstat(struct diff_filepair *p, struct diff_options *o,
|
|
|
|
struct diffstat_t *diffstat)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
const char *other;
|
2006-04-26 06:40:09 +00:00
|
|
|
int complete_rewrite = 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
|
|
|
if (DIFF_PAIR_UNMERGED(p)) {
|
|
|
|
/* unmerged */
|
2006-06-14 15:40:23 +00:00
|
|
|
builtin_diffstat(p->one->path, NULL, NULL, NULL, diffstat, o, 0);
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
diff_fill_sha1_info(p->one);
|
|
|
|
diff_fill_sha1_info(p->two);
|
|
|
|
|
2006-04-26 06:40:09 +00:00
|
|
|
if (p->status == DIFF_STATUS_MODIFIED && p->score)
|
|
|
|
complete_rewrite = 1;
|
2006-06-14 15:40:23 +00:00
|
|
|
builtin_diffstat(name, other, p->one, p->two, diffstat, o, complete_rewrite);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2006-05-20 21:43:13 +00: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-12 22:26:02 +00:00
|
|
|
const char *attr_path;
|
2006-05-20 21:43:13 +00: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-12 22:26:02 +00:00
|
|
|
attr_path = other ? other : name;
|
|
|
|
|
|
|
|
if (o->prefix_length)
|
|
|
|
strip_prefix(o->prefix_length, &name, &other);
|
2006-05-20 21:43:13 +00: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-12 22:26:02 +00:00
|
|
|
builtin_checkdiff(name, other, attr_path, p->one, p->two, o);
|
2006-05-20 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
void diff_setup(struct diff_options *options)
|
|
|
|
{
|
|
|
|
memset(options, 0, sizeof(*options));
|
2008-03-10 02:43:39 +00:00
|
|
|
|
|
|
|
options->file = stdout;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
options->line_termination = '\n';
|
|
|
|
options->break_opt = -1;
|
|
|
|
options->rename_limit = -1;
|
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-12 21:26:31 +00:00
|
|
|
options->dirstat_percent = 3;
|
2006-05-13 20:23:48 +00:00
|
|
|
options->context = 3;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
|
|
|
options->change = diff_change;
|
|
|
|
options->add_remove = diff_addremove;
|
2008-02-18 07:26:03 +00:00
|
|
|
if (diff_use_color_default > 0)
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, COLOR_DIFF);
|
2006-07-07 11:01:23 +00:00
|
|
|
options->detect_rename = diff_detect_rename_default;
|
2007-12-18 19:32:14 +00:00
|
|
|
|
2008-08-19 03:08:09 +00:00
|
|
|
if (!diff_mnemonic_prefix) {
|
|
|
|
options->a_prefix = "a/";
|
|
|
|
options->b_prefix = "b/";
|
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int diff_setup_done(struct diff_options *options)
|
|
|
|
{
|
2006-06-24 17:26:49 +00: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");
|
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(options, FIND_COPIES_HARDER))
|
2006-08-09 20:17:19 +00: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-12 22:26:02 +00: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-24 17:21:53 +00: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 10:01:00 +00:00
|
|
|
DIFF_FORMAT_NUMSTAT |
|
2006-06-24 17:21:53 +00:00
|
|
|
DIFF_FORMAT_DIFFSTAT |
|
2006-12-15 04:15:44 +00: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-12 21:26:31 +00:00
|
|
|
DIFF_FORMAT_DIRSTAT |
|
2006-06-24 17:21:53 +00:00
|
|
|
DIFF_FORMAT_SUMMARY |
|
|
|
|
DIFF_FORMAT_PATCH);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
/*
|
|
|
|
* These cases always need recursive; we do not drop caller-supplied
|
|
|
|
* recursive bits for other formats here.
|
|
|
|
*/
|
2006-06-24 17:21:53 +00:00
|
|
|
if (options->output_format & (DIFF_FORMAT_PATCH |
|
2006-10-12 10:01:00 +00:00
|
|
|
DIFF_FORMAT_NUMSTAT |
|
2006-06-24 17:21:53 +00:00
|
|
|
DIFF_FORMAT_DIFFSTAT |
|
2006-12-15 04:15:44 +00: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-12 21:26:31 +00:00
|
|
|
DIFF_FORMAT_DIRSTAT |
|
2006-10-03 21:09:56 +00:00
|
|
|
DIFF_FORMAT_SUMMARY |
|
2006-06-24 17:21:53 +00:00
|
|
|
DIFF_FORMAT_CHECKDIFF))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, RECURSIVE);
|
2006-05-22 07:31:02 +00:00
|
|
|
/*
|
2006-06-27 22:08:19 +00:00
|
|
|
* Also pickaxe would not work very well if you do not say recursive
|
2006-05-22 07:31:02 +00:00
|
|
|
*/
|
2006-06-27 22:08:19 +00:00
|
|
|
if (options->pickaxe)
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, RECURSIVE);
|
2006-05-22 07:31:02 +00:00
|
|
|
|
2006-04-22 06:57:45 +00: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-14 18:12:13 +00: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.
|
|
|
|
*/
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(options, QUIET)) {
|
2007-03-14 18:12:13 +00:00
|
|
|
options->output_format = DIFF_FORMAT_NO_OUTPUT;
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, EXIT_WITH_STATUS);
|
2007-03-14 18:12:13 +00:00
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-06-24 17:20:32 +00:00
|
|
|
static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val)
|
2006-05-13 20:23:48 +00: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 09:54:57 +00:00
|
|
|
static int diff_scoreopt_parse(const char *opt);
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
int diff_opt_parse(struct diff_options *options, const char **av, int ac)
|
|
|
|
{
|
|
|
|
const char *arg = av[0];
|
2007-11-07 10:20:32 +00:00
|
|
|
|
|
|
|
/* Output format options */
|
2006-04-22 06:57:45 +00:00
|
|
|
if (!strcmp(arg, "-p") || !strcmp(arg, "-u"))
|
2006-06-24 17:21:53 +00:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH;
|
2006-05-13 20:23:48 +00:00
|
|
|
else if (opt_arg(arg, 'U', "unified", &options->context))
|
2006-06-24 17:21:53 +00:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH;
|
2006-06-24 17:23:06 +00:00
|
|
|
else if (!strcmp(arg, "--raw"))
|
|
|
|
options->output_format |= DIFF_FORMAT_RAW;
|
2007-11-10 19:05:14 +00:00
|
|
|
else if (!strcmp(arg, "--patch-with-raw"))
|
2006-06-24 17:21:53 +00:00
|
|
|
options->output_format |= DIFF_FORMAT_PATCH | DIFF_FORMAT_RAW;
|
2007-11-10 19:05:14 +00:00
|
|
|
else if (!strcmp(arg, "--numstat"))
|
2006-10-12 10:01:00 +00:00
|
|
|
options->output_format |= DIFF_FORMAT_NUMSTAT;
|
2007-11-10 19:05:14 +00:00
|
|
|
else if (!strcmp(arg, "--shortstat"))
|
2006-12-15 04:15:44 +00:00
|
|
|
options->output_format |= 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-12 21:26:31 +00:00
|
|
|
else if (opt_arg(arg, 'X', "dirstat", &options->dirstat_percent))
|
|
|
|
options->output_format |= DIFF_FORMAT_DIRSTAT;
|
2008-09-03 00:28:59 +00:00
|
|
|
else if (!strcmp(arg, "--cumulative")) {
|
|
|
|
options->output_format |= DIFF_FORMAT_DIRSTAT;
|
|
|
|
DIFF_OPT_SET(options, DIRSTAT_CUMULATIVE);
|
2008-09-05 19:27:35 +00:00
|
|
|
} else if (opt_arg(arg, 0, "dirstat-by-file",
|
|
|
|
&options->dirstat_percent)) {
|
|
|
|
options->output_format |= DIFF_FORMAT_DIRSTAT;
|
|
|
|
DIFF_OPT_SET(options, DIRSTAT_BY_FILE);
|
2008-09-03 00:28:59 +00:00
|
|
|
}
|
2007-11-07 10:20:32 +00: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;
|
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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(arg, "--stat")) {
|
2006-09-28 22:07:16 +00:00
|
|
|
char *end;
|
|
|
|
int width = options->stat_width;
|
|
|
|
int name_width = options->stat_name_width;
|
|
|
|
arg += 6;
|
|
|
|
end = (char *)arg;
|
|
|
|
|
|
|
|
switch (*arg) {
|
|
|
|
case '-':
|
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 09:53:29 +00:00
|
|
|
if (!prefixcmp(arg, "-width="))
|
2006-09-28 22:07:16 +00:00
|
|
|
width = strtoul(arg + 7, &end, 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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(arg, "-name-width="))
|
2006-09-28 22:07:16 +00:00
|
|
|
name_width = strtoul(arg + 12, &end, 10);
|
|
|
|
break;
|
|
|
|
case '=':
|
|
|
|
width = strtoul(arg+1, &end, 10);
|
|
|
|
if (*end == ',')
|
|
|
|
name_width = strtoul(end+1, &end, 10);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Important! This checks all the error cases! */
|
|
|
|
if (*end)
|
|
|
|
return 0;
|
2006-06-24 17:21:53 +00:00
|
|
|
options->output_format |= DIFF_FORMAT_DIFFSTAT;
|
2006-09-28 22:07:16 +00:00
|
|
|
options->stat_name_width = name_width;
|
|
|
|
options->stat_width = width;
|
2006-09-27 01:53:02 +00:00
|
|
|
}
|
2007-11-07 10:20:32 +00:00
|
|
|
|
|
|
|
/* renames options */
|
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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(arg, "-B")) {
|
2007-11-10 19:05:14 +00:00
|
|
|
if ((options->break_opt = diff_scoreopt_parse(arg)) == -1)
|
2006-04-22 06:57:45 +00:00
|
|
|
return -1;
|
|
|
|
}
|
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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(arg, "-M")) {
|
2007-11-10 19:05:14 +00:00
|
|
|
if ((options->rename_score = diff_scoreopt_parse(arg)) == -1)
|
2006-04-22 06:57:45 +00:00
|
|
|
return -1;
|
|
|
|
options->detect_rename = DIFF_DETECT_RENAME;
|
|
|
|
}
|
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 09:53:29 +00:00
|
|
|
else if (!prefixcmp(arg, "-C")) {
|
2007-06-11 20:12:19 +00:00
|
|
|
if (options->detect_rename == DIFF_DETECT_COPY)
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
|
|
|
|
if ((options->rename_score = diff_scoreopt_parse(arg)) == -1)
|
2006-04-22 06:57:45 +00:00
|
|
|
return -1;
|
|
|
|
options->detect_rename = DIFF_DETECT_COPY;
|
|
|
|
}
|
2007-11-07 10:20:32 +00:00
|
|
|
else if (!strcmp(arg, "--no-renames"))
|
|
|
|
options->detect_rename = 0;
|
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-12 22:26:02 +00:00
|
|
|
else if (!strcmp(arg, "--relative"))
|
|
|
|
DIFF_OPT_SET(options, RELATIVE_NAME);
|
2008-02-13 08:34:39 +00:00
|
|
|
else if (!prefixcmp(arg, "--relative=")) {
|
|
|
|
DIFF_OPT_SET(options, RELATIVE_NAME);
|
|
|
|
options->prefix = arg + 11;
|
|
|
|
}
|
2007-11-07 10:20:32 +00:00
|
|
|
|
|
|
|
/* xdiff options */
|
|
|
|
else if (!strcmp(arg, "-w") || !strcmp(arg, "--ignore-all-space"))
|
|
|
|
options->xdl_opts |= XDF_IGNORE_WHITESPACE;
|
|
|
|
else if (!strcmp(arg, "-b") || !strcmp(arg, "--ignore-space-change"))
|
|
|
|
options->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
|
|
|
|
else if (!strcmp(arg, "--ignore-space-at-eol"))
|
|
|
|
options->xdl_opts |= XDF_IGNORE_WHITESPACE_AT_EOL;
|
2009-01-01 16:39:17 +00:00
|
|
|
else if (!strcmp(arg, "--patience"))
|
|
|
|
options->xdl_opts |= XDF_PATIENCE_DIFF;
|
2007-11-07 10:20:32 +00: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 06:57:45 +00:00
|
|
|
else if (!strcmp(arg, "--find-copies-harder"))
|
2007-11-10 19:05:14 +00: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-19 21:22:46 +00:00
|
|
|
else if (!strcmp(arg, "--follow"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, FOLLOW_RENAMES);
|
2006-06-13 16:45:44 +00:00
|
|
|
else if (!strcmp(arg, "--color"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, COLOR_DIFF);
|
2006-07-07 12:27:24 +00:00
|
|
|
else if (!strcmp(arg, "--no-color"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_CLR(options, COLOR_DIFF);
|
2006-07-28 21:56:15 +00:00
|
|
|
else if (!strcmp(arg, "--color-words"))
|
2007-11-10 19:05:14 +00:00
|
|
|
options->flags |= DIFF_OPT_COLOR_DIFF | DIFF_OPT_COLOR_DIFF_WORDS;
|
2009-01-17 16:29:45 +00:00
|
|
|
else if (!prefixcmp(arg, "--color-words=")) {
|
|
|
|
options->flags |= DIFF_OPT_COLOR_DIFF | DIFF_OPT_COLOR_DIFF_WORDS;
|
|
|
|
options->word_regex = arg + 14;
|
|
|
|
}
|
2007-03-14 00:17:04 +00:00
|
|
|
else if (!strcmp(arg, "--exit-code"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, EXIT_WITH_STATUS);
|
2007-03-14 18:12:13 +00:00
|
|
|
else if (!strcmp(arg, "--quiet"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, QUIET);
|
2007-06-30 17:47:07 +00:00
|
|
|
else if (!strcmp(arg, "--ext-diff"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, ALLOW_EXTERNAL);
|
2007-06-30 17:47:07 +00:00
|
|
|
else if (!strcmp(arg, "--no-ext-diff"))
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
|
2008-12-08 02:57:01 +00:00
|
|
|
else if (!strcmp(arg, "--textconv"))
|
|
|
|
DIFF_OPT_SET(options, ALLOW_TEXTCONV);
|
|
|
|
else if (!strcmp(arg, "--no-textconv"))
|
|
|
|
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
|
2008-05-14 17:03:31 +00:00
|
|
|
else if (!strcmp(arg, "--ignore-submodules"))
|
|
|
|
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
|
2007-11-07 10:20:32 +00:00
|
|
|
|
|
|
|
/* misc options */
|
|
|
|
else if (!strcmp(arg, "-z"))
|
|
|
|
options->line_termination = 0;
|
|
|
|
else if (!prefixcmp(arg, "-l"))
|
|
|
|
options->rename_limit = strtoul(arg+2, NULL, 10);
|
|
|
|
else if (!prefixcmp(arg, "-S"))
|
|
|
|
options->pickaxe = arg + 2;
|
|
|
|
else if (!strcmp(arg, "--pickaxe-all"))
|
|
|
|
options->pickaxe_opts = DIFF_PICKAXE_ALL;
|
|
|
|
else if (!strcmp(arg, "--pickaxe-regex"))
|
|
|
|
options->pickaxe_opts = DIFF_PICKAXE_REGEX;
|
|
|
|
else if (!prefixcmp(arg, "-O"))
|
|
|
|
options->orderfile = arg + 2;
|
|
|
|
else if (!prefixcmp(arg, "--diff-filter="))
|
|
|
|
options->filter = arg + 14;
|
|
|
|
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;
|
|
|
|
}
|
2007-12-18 19:32:14 +00:00
|
|
|
else if (!prefixcmp(arg, "--src-prefix="))
|
|
|
|
options->a_prefix = arg + 13;
|
|
|
|
else if (!prefixcmp(arg, "--dst-prefix="))
|
|
|
|
options->b_prefix = arg + 13;
|
|
|
|
else if (!strcmp(arg, "--no-prefix"))
|
|
|
|
options->a_prefix = options->b_prefix = "";
|
2008-12-28 18:45:32 +00:00
|
|
|
else if (opt_arg(arg, '\0', "inter-hunk-context",
|
|
|
|
&options->interhunkcontext))
|
|
|
|
;
|
2008-03-10 02:43:39 +00:00
|
|
|
else if (!prefixcmp(arg, "--output=")) {
|
|
|
|
options->file = fopen(arg + strlen("--output="), "w");
|
|
|
|
options->close_file = 1;
|
|
|
|
} else
|
2006-04-22 06:57:45 +00:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_num(const char **cp_p)
|
|
|
|
{
|
|
|
|
unsigned long num, scale;
|
|
|
|
int ch, dot;
|
|
|
|
const char *cp = *cp_p;
|
|
|
|
|
|
|
|
num = 0;
|
|
|
|
scale = 1;
|
|
|
|
dot = 0;
|
|
|
|
for(;;) {
|
|
|
|
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 01:44:37 +00:00
|
|
|
return (int)((num >= scale) ? MAX_SCORE : (MAX_SCORE * num / scale));
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2007-06-08 09:54:57 +00:00
|
|
|
static int diff_scoreopt_parse(const char *opt)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int opt1, opt2, cmd;
|
|
|
|
|
|
|
|
if (*opt++ != '-')
|
|
|
|
return -1;
|
|
|
|
cmd = *opt++;
|
|
|
|
if (cmd != 'M' && cmd != 'C' && cmd != 'B')
|
|
|
|
return -1; /* that is not a -M, -C nor -B option */
|
|
|
|
|
|
|
|
opt1 = parse_num(&opt);
|
|
|
|
if (cmd != 'B')
|
|
|
|
opt2 = 0;
|
|
|
|
else {
|
|
|
|
if (*opt == 0)
|
|
|
|
opt2 = 0;
|
|
|
|
else if (*opt != '/')
|
|
|
|
return -1; /* we expect -B80/99 or -B80 */
|
|
|
|
else {
|
|
|
|
opt++;
|
|
|
|
opt2 = parse_num(&opt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
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-03 19:01:01 +00:00
|
|
|
struct diff_filepair *dp = xcalloc(1, sizeof(*dp));
|
2006-04-22 06:57:45 +00: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-25 18:19:10 +00:00
|
|
|
free_filespec(p->one);
|
|
|
|
free_filespec(p->two);
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
static void diff_flush_raw(struct diff_filepair *p, struct diff_options *opt)
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
int line_termination = opt->line_termination;
|
|
|
|
int inter_name_termination = line_termination ? '\t' : '\0';
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
if (!(opt->output_format & DIFF_FORMAT_NAME_STATUS)) {
|
2008-03-10 02:43:39 +00: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 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
if (p->score) {
|
2008-03-10 02:43:39 +00: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-19 22:42:15 +00:00
|
|
|
} else {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(opt->file, "%c%c", p->status, inter_name_termination);
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00: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 02:43:39 +00: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-19 22:42:15 +00: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-12 22:26:02 +00: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 02:43:39 +00: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-19 22:42:15 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00: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-19 22:42:15 +00:00
|
|
|
struct diff_filespec *one = p->one, *two = p->two;
|
2006-04-22 06:57:45 +00: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 &&
|
2006-08-17 18:54:57 +00:00
|
|
|
!hashcmp(one->sha1, two->sha1))
|
2006-04-22 06:57:45 +00: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)))
|
|
|
|
return; /* no tree diffs in patch format */
|
|
|
|
|
|
|
|
run_diffstat(p, o, diffstat);
|
|
|
|
}
|
|
|
|
|
2006-05-20 21:43:13 +00: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)))
|
|
|
|
return; /* no tree diffs in patch format */
|
|
|
|
|
|
|
|
run_checkdiff(p, o);
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00: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-25 18:20:56 +00:00
|
|
|
fprintf(stderr, "score %d, status %c rename_used %d broken %d\n",
|
2006-04-22 06:57:45 +00:00
|
|
|
p->score, p->status ? p->status : '?',
|
2007-10-25 18:20:56 +00:00
|
|
|
p->one->rename_used, p->broken_pair);
|
2006-04-22 06:57:45 +00: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-25 18:20:56 +00:00
|
|
|
int i;
|
|
|
|
struct diff_filepair *p;
|
2006-04-22 06:57:45 +00: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-25 18:20:56 +00: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 06:57:45 +00:00
|
|
|
*/
|
2007-10-25 18:20:56 +00:00
|
|
|
if (!strcmp(p->one->path, p->two->path))
|
|
|
|
p->status = DIFF_STATUS_MODIFIED;
|
|
|
|
else if (--p->one->rename_used > 0)
|
2006-04-22 06:57:45 +00:00
|
|
|
p->status = DIFF_STATUS_COPIED;
|
2007-10-25 18:20:56 +00:00
|
|
|
else
|
2006-04-22 06:57:45 +00:00
|
|
|
p->status = DIFF_STATUS_RENAMED;
|
|
|
|
}
|
2006-08-17 18:54:57 +00:00
|
|
|
else if (hashcmp(p->one->sha1, p->two->sha1) ||
|
2007-02-22 20:50:10 +00:00
|
|
|
p->one->mode != p->two->mode ||
|
|
|
|
is_null_sha1(p->one->sha1))
|
2006-04-22 06:57:45 +00: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-24 17:21:53 +00:00
|
|
|
static int check_pair_status(struct diff_filepair *p)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
switch (p->status) {
|
|
|
|
case DIFF_STATUS_UNKNOWN:
|
2006-06-24 17:21:53 +00:00
|
|
|
return 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
case 0:
|
|
|
|
die("internal error in diff-resolve-rename-copy");
|
|
|
|
default:
|
2006-06-24 17:21:53 +00:00
|
|
|
return 1;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-24 17:21:53 +00: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-12 22:26:02 +00: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 02:43:39 +00: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-12 22:26:02 +00:00
|
|
|
}
|
2006-06-24 17:21:53 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_file_mode_name(FILE *file, const char *newdelete, struct diff_filespec *fs)
|
2006-05-14 12:13:49 +00:00
|
|
|
{
|
|
|
|
if (fs->mode)
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, " %s mode %06o ", newdelete, fs->mode);
|
2006-05-14 12:13:49 +00:00
|
|
|
else
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, " %s ", newdelete);
|
|
|
|
write_name_quoted(fs->path, file, '\n');
|
2006-05-14 12:13:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_mode_change(FILE *file, struct diff_filepair *p, int show_name)
|
2006-05-14 12:13:49 +00:00
|
|
|
{
|
|
|
|
if (p->one->mode && p->two->mode && p->one->mode != p->two->mode) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, " mode change %06o => %06o%c", p->one->mode, p->two->mode,
|
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-19 22:42:15 +00:00
|
|
|
show_name ? ' ' : '\n');
|
2007-02-10 14:37:48 +00:00
|
|
|
if (show_name) {
|
2008-03-10 02:43:39 +00:00
|
|
|
write_name_quoted(p->two->path, file, '\n');
|
2007-02-10 14:37:48 +00:00
|
|
|
}
|
2006-05-14 12:13:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void show_rename_copy(FILE *file, const char *renamecopy, struct diff_filepair *p)
|
2006-05-14 12:13:49 +00:00
|
|
|
{
|
2007-02-10 14:36:47 +00:00
|
|
|
char *names = pprint_rename(p->one->path, p->two->path);
|
2006-05-14 12:13:49 +00:00
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
fprintf(file, " %s %s (%d%%)\n", renamecopy, names, similarity_index(p));
|
2007-02-10 14:36:47 +00:00
|
|
|
free(names);
|
2008-03-10 02:43:39 +00:00
|
|
|
show_mode_change(file, p, 0);
|
2006-05-14 12:13:49 +00:00
|
|
|
}
|
|
|
|
|
2008-03-10 02:43:39 +00:00
|
|
|
static void diff_summary(FILE *file, struct diff_filepair *p)
|
2006-05-14 12:13:49 +00:00
|
|
|
{
|
|
|
|
switch(p->status) {
|
|
|
|
case DIFF_STATUS_DELETED:
|
2008-03-10 02:43:39 +00:00
|
|
|
show_file_mode_name(file, "delete", p->one);
|
2006-05-14 12:13:49 +00:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_ADDED:
|
2008-03-10 02:43:39 +00:00
|
|
|
show_file_mode_name(file, "create", p->two);
|
2006-05-14 12:13:49 +00:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_COPIED:
|
2008-03-10 02:43:39 +00:00
|
|
|
show_rename_copy(file, "copy", p);
|
2006-05-14 12:13:49 +00:00
|
|
|
break;
|
|
|
|
case DIFF_STATUS_RENAMED:
|
2008-03-10 02:43:39 +00:00
|
|
|
show_rename_copy(file, "rename", p);
|
2006-05-14 12:13:49 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (p->score) {
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(" rewrite ", file);
|
|
|
|
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-19 22:42:15 +00:00
|
|
|
}
|
2008-03-10 02:43:39 +00:00
|
|
|
show_mode_change(file, p, !p->score);
|
2006-05-14 12:13:49 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-25 01:51:08 +00:00
|
|
|
struct patch_id_t {
|
2008-10-01 18:05:20 +00:00
|
|
|
git_SHA_CTX *ctx;
|
2006-06-25 01:51:08 +00: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-19 22:42:15 +00:00
|
|
|
char *dst = line;
|
|
|
|
unsigned char c;
|
2006-06-25 01:51:08 +00: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-19 22:42:15 +00:00
|
|
|
for (i = 0; i < len; i++)
|
|
|
|
if (!isspace((c = line[i])))
|
|
|
|
*dst++ = c;
|
2006-06-25 01:51:08 +00: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-19 22:42:15 +00:00
|
|
|
return dst - line;
|
2006-06-25 01:51:08 +00: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 09:53:29 +00:00
|
|
|
if (!prefixcmp(line, "@@ -"))
|
2006-06-25 01:51:08 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
new_len = remove_space(line, len);
|
|
|
|
|
2008-10-01 18:05:20 +00:00
|
|
|
git_SHA1_Update(data->ctx, line, new_len);
|
2006-06-25 01:51:08 +00: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-01 18:05:20 +00:00
|
|
|
git_SHA_CTX ctx;
|
2006-06-25 01:51:08 +00:00
|
|
|
struct patch_id_t data;
|
|
|
|
char buffer[PATH_MAX * 4 + 20];
|
|
|
|
|
2008-10-01 18:05:20 +00:00
|
|
|
git_SHA1_Init(&ctx);
|
2006-06-25 01:51:08 +00: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;
|
|
|
|
xdemitcb_t ecb;
|
|
|
|
mmfile_t mf1, mf2;
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
int len1, len2;
|
|
|
|
|
2008-10-25 13:30:37 +00:00
|
|
|
memset(&xpp, 0, sizeof(xpp));
|
2007-07-04 18:05:46 +00:00
|
|
|
memset(&xecfg, 0, sizeof(xecfg));
|
2006-06-25 01:51:08 +00: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-01 18:05:20 +00:00
|
|
|
git_SHA1_Update(&ctx, buffer, len1);
|
2006-06-25 01:51:08 +00:00
|
|
|
|
|
|
|
xpp.flags = XDF_NEED_MINIMAL;
|
|
|
|
xecfg.ctxlen = 3;
|
2006-06-29 05:49:42 +00:00
|
|
|
xecfg.flags = XDL_EMIT_FUNCNAMES;
|
2008-08-14 06:18:22 +00:00
|
|
|
xdi_diff_outf(&mf1, &mf2, patch_id_consume, &data,
|
|
|
|
&xpp, &xecfg, &ecb);
|
2006-06-25 01:51:08 +00:00
|
|
|
}
|
|
|
|
|
2008-10-01 18:05:20 +00:00
|
|
|
git_SHA1_Final(sha1, &ctx);
|
2006-06-25 01:51:08 +00: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);
|
|
|
|
q->queue = NULL;
|
|
|
|
q->nr = q->alloc = 0;
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2006-06-27 12:09:17 +00:00
|
|
|
static int is_summary_empty(const struct diff_queue_struct *q)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2006-06-27 12:09:17 +00: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 06:57:45 +00:00
|
|
|
}
|
2006-06-27 12:09:17 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
void diff_flush(struct diff_options *options)
|
|
|
|
{
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2006-06-24 17:21:53 +00:00
|
|
|
int i, output_format = options->output_format;
|
2006-06-27 12:09:17 +00:00
|
|
|
int separator = 0;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-06-24 17:21:53 +00:00
|
|
|
/*
|
|
|
|
* Order: raw, stat, summary, patch
|
|
|
|
* or: name/name-status/checkdiff (other bits clear)
|
|
|
|
*/
|
2006-06-27 12:09:17 +00:00
|
|
|
if (!q->nr)
|
|
|
|
goto free_queue;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-06-24 17:21:53 +00:00
|
|
|
if (output_format & (DIFF_FORMAT_RAW |
|
|
|
|
DIFF_FORMAT_NAME |
|
|
|
|
DIFF_FORMAT_NAME_STATUS |
|
|
|
|
DIFF_FORMAT_CHECKDIFF)) {
|
2006-04-22 06:57:45 +00:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
2006-06-24 17:21:53 +00:00
|
|
|
if (check_pair_status(p))
|
|
|
|
flush_one_pair(p, options);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2006-06-27 12:09:17 +00:00
|
|
|
separator++;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2006-06-24 17:21:53 +00:00
|
|
|
|
2008-02-13 01:06:58 +00:00
|
|
|
if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_SHORTSTAT|DIFF_FORMAT_NUMSTAT)) {
|
2006-06-25 11:28:19 +00:00
|
|
|
struct diffstat_t diffstat;
|
2006-06-24 17:21:53 +00:00
|
|
|
|
2006-06-25 11:28:19 +00:00
|
|
|
memset(&diffstat, 0, sizeof(struct diffstat_t));
|
2006-04-22 06:57:45 +00:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
2006-06-24 17:21:53 +00:00
|
|
|
if (check_pair_status(p))
|
2006-06-25 11:28:19 +00:00
|
|
|
diff_flush_stat(p, options, &diffstat);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2006-10-12 10:01:00 +00:00
|
|
|
if (output_format & DIFF_FORMAT_NUMSTAT)
|
|
|
|
show_numstat(&diffstat, options);
|
|
|
|
if (output_format & DIFF_FORMAT_DIFFSTAT)
|
|
|
|
show_stats(&diffstat, options);
|
2007-12-12 07:46:30 +00:00
|
|
|
if (output_format & DIFF_FORMAT_SHORTSTAT)
|
2008-03-10 02:43:39 +00:00
|
|
|
show_shortstats(&diffstat, options);
|
2007-12-12 07:46:30 +00:00
|
|
|
free_diffstat_info(&diffstat);
|
2006-06-27 22:08:19 +00:00
|
|
|
separator++;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2008-02-13 01:06:58 +00:00
|
|
|
if (output_format & DIFF_FORMAT_DIRSTAT)
|
|
|
|
show_dirstat(options);
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-06-27 12:09:17 +00:00
|
|
|
if (output_format & DIFF_FORMAT_SUMMARY && !is_summary_empty(q)) {
|
2006-06-24 17:21:53 +00:00
|
|
|
for (i = 0; i < q->nr; i++)
|
2008-03-10 02:43:39 +00:00
|
|
|
diff_summary(options->file, q->queue[i]);
|
2006-06-27 22:08:19 +00:00
|
|
|
separator++;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2006-06-24 17:21:53 +00:00
|
|
|
if (output_format & DIFF_FORMAT_PATCH) {
|
2006-06-27 12:09:17 +00:00
|
|
|
if (separator) {
|
2008-07-30 05:49:33 +00:00
|
|
|
putc(options->line_termination, options->file);
|
2006-06-27 12:09:17 +00:00
|
|
|
if (options->stat_sep) {
|
|
|
|
/* attach patch instead of inline */
|
2008-03-10 02:43:39 +00:00
|
|
|
fputs(options->stat_sep, options->file);
|
2006-06-27 12:09:17 +00:00
|
|
|
}
|
2006-06-24 17:21:53 +00: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 12:13:49 +00:00
|
|
|
}
|
|
|
|
|
2006-09-07 06:35:42 +00:00
|
|
|
if (output_format & DIFF_FORMAT_CALLBACK)
|
|
|
|
options->format_callback(q, options, options->format_callback_data);
|
|
|
|
|
2006-06-24 17:21:53 +00:00
|
|
|
for (i = 0; i < q->nr; i++)
|
|
|
|
diff_free_filepair(q->queue[i]);
|
2006-06-27 12:09:17 +00:00
|
|
|
free_queue:
|
2006-04-22 06:57:45 +00:00
|
|
|
free(q->queue);
|
|
|
|
q->queue = NULL;
|
|
|
|
q->nr = q->alloc = 0;
|
2008-03-10 02:43:39 +00:00
|
|
|
if (options->close_file)
|
|
|
|
fclose(options->file);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void diffcore_apply_filter(const char *filter)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
|
|
struct diff_queue_struct outq;
|
|
|
|
outq.queue = NULL;
|
|
|
|
outq.nr = outq.alloc = 0;
|
|
|
|
|
|
|
|
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 10:30:22 +00: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 08:07:59 +00:00
|
|
|
if (S_ISGITLINK(one->mode))
|
|
|
|
return 0;
|
2007-09-08 10:30:22 +00: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-03 20:33:31 +00: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;
|
|
|
|
outq.queue = NULL;
|
|
|
|
outq.nr = outq.alloc = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 1. Entries that come from stat info dirtyness
|
|
|
|
* 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 10:30:22 +00: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-03 20:33:31 +00: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-10 19:05:14 +00:00
|
|
|
if (!DIFF_OPT_TST(diffopt, NO_INDEX))
|
2007-08-14 22:41:00 +00: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-03 20:33:31 +00:00
|
|
|
diff_free_filepair(p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(q->queue);
|
|
|
|
*q = outq;
|
|
|
|
}
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
void diffcore_std(struct diff_options *options)
|
|
|
|
{
|
2008-09-07 02:09:16 +00: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-03 20:33:31 +00:00
|
|
|
diffcore_skip_stat_unmatch(options);
|
2006-04-22 06:57:45 +00:00
|
|
|
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();
|
|
|
|
if (options->pickaxe)
|
|
|
|
diffcore_pickaxe(options->pickaxe, options->pickaxe_opts);
|
|
|
|
if (options->orderfile)
|
|
|
|
diffcore_order(options->orderfile);
|
|
|
|
diff_resolve_rename_copy();
|
|
|
|
diffcore_apply_filter(options->filter);
|
2007-03-14 18:12:13 +00:00
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (diff_queued_diff.nr)
|
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
|
|
|
else
|
|
|
|
DIFF_OPT_CLR(options, HAS_CHANGES);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
2007-12-14 07:40:27 +00:00
|
|
|
int diff_result_code(struct diff_options *opt, int status)
|
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
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 06:57:45 +00:00
|
|
|
|
|
|
|
void diff_addremove(struct diff_options *options,
|
|
|
|
int addremove, unsigned mode,
|
|
|
|
const unsigned char *sha1,
|
2008-07-16 14:54:02 +00:00
|
|
|
const char *concatpath)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
struct diff_filespec *one, *two;
|
|
|
|
|
2008-05-14 17:03:31 +00:00
|
|
|
if (DIFF_OPT_TST(options, IGNORE_SUBMODULES) && S_ISGITLINK(mode))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 06:57:45 +00: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 07:04:01 +00:00
|
|
|
* Feeding the same new and old to diff_change()
|
2006-04-22 06:57:45 +00:00
|
|
|
* also has the same effect.
|
|
|
|
* Before the final output happens, they are pruned after
|
|
|
|
* merged into rename/copy pairs as appropriate.
|
|
|
|
*/
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(options, REVERSE_DIFF))
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(concatpath, options->prefix, options->prefix_length))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
one = alloc_filespec(concatpath);
|
|
|
|
two = alloc_filespec(concatpath);
|
|
|
|
|
|
|
|
if (addremove != '+')
|
|
|
|
fill_filespec(one, sha1, mode);
|
|
|
|
if (addremove != '-')
|
|
|
|
fill_filespec(two, sha1, mode);
|
|
|
|
|
|
|
|
diff_queue(&diff_queued_diff, one, two);
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_change(struct diff_options *options,
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
|
|
|
const unsigned char *old_sha1,
|
|
|
|
const unsigned char *new_sha1,
|
2008-07-16 14:54:02 +00:00
|
|
|
const char *concatpath)
|
2006-04-22 06:57:45 +00:00
|
|
|
{
|
|
|
|
struct diff_filespec *one, *two;
|
|
|
|
|
2008-05-14 17:03:31 +00:00
|
|
|
if (DIFF_OPT_TST(options, IGNORE_SUBMODULES) && S_ISGITLINK(old_mode)
|
|
|
|
&& S_ISGITLINK(new_mode))
|
|
|
|
return;
|
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(options, REVERSE_DIFF)) {
|
2006-04-22 06:57:45 +00: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 --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-12 22:26:02 +00:00
|
|
|
|
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(concatpath, options->prefix, options->prefix_length))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
one = alloc_filespec(concatpath);
|
|
|
|
two = alloc_filespec(concatpath);
|
|
|
|
fill_filespec(one, old_sha1, old_mode);
|
|
|
|
fill_filespec(two, new_sha1, new_mode);
|
|
|
|
|
|
|
|
diff_queue(&diff_queued_diff, one, two);
|
2007-11-10 19:05:14 +00:00
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void diff_unmerge(struct diff_options *options,
|
2007-01-05 09:25:18 +00:00
|
|
|
const char *path,
|
|
|
|
unsigned mode, const unsigned char *sha1)
|
2006-04-22 06:57:45 +00: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-12 22:26:02 +00:00
|
|
|
|
|
|
|
if (options->prefix &&
|
|
|
|
strncmp(path, options->prefix, options->prefix_length))
|
|
|
|
return;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
one = alloc_filespec(path);
|
|
|
|
two = alloc_filespec(path);
|
2007-01-05 09:25:18 +00:00
|
|
|
fill_filespec(one, sha1, mode);
|
|
|
|
diff_queue(&diff_queued_diff, one, two)->is_unmerged = 1;
|
2006-04-22 06:57:45 +00:00
|
|
|
}
|
2008-10-05 21:43:45 +00: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 05:59:56 +00:00
|
|
|
struct diff_tempfile *temp;
|
2008-10-05 21:43:45 +00:00
|
|
|
const char *argv[3];
|
|
|
|
const char **arg = argv;
|
|
|
|
struct child_process child;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
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 05:59:56 +00:00
|
|
|
temp = prepare_temp_file(spec->path, spec);
|
2008-10-05 21:43:45 +00: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 05:59:56 +00:00
|
|
|
*arg++ = temp->name;
|
2008-10-05 21:43:45 +00:00
|
|
|
*arg = NULL;
|
|
|
|
|
|
|
|
memset(&child, 0, sizeof(child));
|
|
|
|
child.argv = argv;
|
|
|
|
child.out = -1;
|
|
|
|
if (start_command(&child) != 0 ||
|
|
|
|
strbuf_read(&buf, child.out, 0) < 0 ||
|
|
|
|
finish_command(&child) != 0) {
|
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 05:59:56 +00:00
|
|
|
remove_tempfile();
|
2008-10-05 21:43:45 +00:00
|
|
|
error("error running textconv command '%s'", pgm);
|
|
|
|
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 05:59:56 +00:00
|
|
|
remove_tempfile();
|
2008-10-05 21:43:45 +00:00
|
|
|
|
|
|
|
return strbuf_detach(&buf, outsize);
|
|
|
|
}
|