2005-05-23 17:52:17 +00:00
|
|
|
/*
|
|
|
|
* apply.c
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*
|
|
|
|
* This applies patches on top of some (arbitrary) version of the SCM.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
2014-10-01 10:28:42 +00:00
|
|
|
#include "lockfile.h"
|
2006-04-23 23:52:52 +00:00
|
|
|
#include "cache-tree.h"
|
2005-10-15 04:54:52 +00:00
|
|
|
#include "quote.h"
|
2006-04-02 12:44:09 +00:00
|
|
|
#include "blob.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-05-23 12:15:34 +00:00
|
|
|
#include "builtin.h"
|
2008-07-21 18:03:49 +00:00
|
|
|
#include "string-list.h"
|
2008-09-26 22:59:14 +00:00
|
|
|
#include "dir.h"
|
2012-02-01 12:55:07 +00:00
|
|
|
#include "diff.h"
|
2008-12-27 23:03:57 +00:00
|
|
|
#include "parse-options.h"
|
2012-05-09 23:10:51 +00:00
|
|
|
#include "xdiff-interface.h"
|
|
|
|
#include "ll-merge.h"
|
2012-05-10 20:56:49 +00:00
|
|
|
#include "rerere.h"
|
2016-08-08 21:02:59 +00:00
|
|
|
#include "apply.h"
|
2016-05-11 13:16:19 +00:00
|
|
|
|
2008-12-27 23:03:57 +00:00
|
|
|
static const char * const apply_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git apply [<options>] [<patch>...]"),
|
2008-12-27 23:03:57 +00:00
|
|
|
NULL
|
|
|
|
};
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2016-05-24 08:11:14 +00:00
|
|
|
static void set_default_whitespace_mode(struct apply_state *state)
|
2006-02-28 09:12:52 +00:00
|
|
|
{
|
2016-05-24 08:11:14 +00:00
|
|
|
if (!state->whitespace_option && !apply_default_whitespace)
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action = (state->apply ? warn_on_ws_error : nowarn_ws_error);
|
2006-02-28 09:12:52 +00:00
|
|
|
}
|
|
|
|
|
2006-08-15 09:23:06 +00:00
|
|
|
/*
|
|
|
|
* This represents one "hunk" from a patch, starting with
|
|
|
|
* "@@ -oldpos,oldlines +newpos,newlines @@" marker. The
|
|
|
|
* patch text is pointed at by patch, and its byte length
|
|
|
|
* is stored in size. leading and trailing are the number
|
|
|
|
* of context lines.
|
|
|
|
*/
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment {
|
2006-04-10 09:33:06 +00:00
|
|
|
unsigned long leading, trailing;
|
2005-05-26 17:23:51 +00:00
|
|
|
unsigned long oldpos, oldlines;
|
|
|
|
unsigned long newpos, newlines;
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* 'patch' is usually borrowed from buf in apply_patch(),
|
|
|
|
* but some codepaths store an allocated buffer.
|
|
|
|
*/
|
2005-05-26 17:23:51 +00:00
|
|
|
const char *patch;
|
2012-03-07 22:21:25 +00:00
|
|
|
unsigned free_patch:1,
|
|
|
|
rejected:1;
|
2005-05-26 17:23:51 +00:00
|
|
|
int size;
|
apply --whitespace=warn/error: diagnose blank at EOF
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 23:02:32 +00:00
|
|
|
int linenr;
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment *next;
|
|
|
|
};
|
|
|
|
|
2006-08-15 09:23:06 +00:00
|
|
|
/*
|
|
|
|
* When dealing with a binary patch, we reuse "leading" field
|
|
|
|
* to store the type of the binary hunk, either deflated "delta"
|
|
|
|
* or deflated "literal".
|
|
|
|
*/
|
|
|
|
#define binary_patch_method leading
|
|
|
|
#define BINARY_DELTA_DEFLATED 1
|
|
|
|
#define BINARY_LITERAL_DEFLATED 2
|
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* This represents a "patch" to a file, both metainfo changes
|
|
|
|
* such as creation/deletion, filemode and content changes represented
|
|
|
|
* as a series of fragments.
|
|
|
|
*/
|
2005-05-26 17:23:51 +00:00
|
|
|
struct patch {
|
2005-05-26 20:11:24 +00:00
|
|
|
char *new_name, *old_name, *def_name;
|
2005-05-26 17:23:51 +00:00
|
|
|
unsigned int old_mode, new_mode;
|
2006-11-18 12:07:09 +00:00
|
|
|
int is_new, is_delete; /* -1 = unknown, 0 = false, 1 = true */
|
2006-08-17 00:55:29 +00:00
|
|
|
int rejected;
|
2007-12-06 08:14:14 +00:00
|
|
|
unsigned ws_rule;
|
2005-05-26 18:40:43 +00:00
|
|
|
int lines_added, lines_deleted;
|
2005-06-22 09:29:46 +00:00
|
|
|
int score;
|
2007-02-21 22:31:10 +00:00
|
|
|
unsigned int is_toplevel_relative:1;
|
2006-11-18 12:07:09 +00:00
|
|
|
unsigned int inaccurate_eof:1;
|
|
|
|
unsigned int is_binary:1;
|
|
|
|
unsigned int is_copy:1;
|
|
|
|
unsigned int is_rename:1;
|
2008-06-27 17:43:09 +00:00
|
|
|
unsigned int recount:1;
|
2012-05-09 23:10:51 +00:00
|
|
|
unsigned int conflicted_threeway:1;
|
2012-06-07 22:04:11 +00:00
|
|
|
unsigned int direct_to_threeway:1;
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment *fragments;
|
2005-06-05 21:05:43 +00:00
|
|
|
char *result;
|
2007-10-21 09:23:49 +00:00
|
|
|
size_t resultsize;
|
2005-10-07 10:42:00 +00:00
|
|
|
char old_sha1_prefix[41];
|
|
|
|
char new_sha1_prefix[41];
|
2005-05-26 17:23:51 +00:00
|
|
|
struct patch *next;
|
2012-05-09 23:10:51 +00:00
|
|
|
|
|
|
|
/* three-way fallback result */
|
2015-03-13 23:39:36 +00:00
|
|
|
struct object_id threeway_stage[3];
|
2005-05-26 17:23:51 +00:00
|
|
|
};
|
2005-05-23 21:38:49 +00:00
|
|
|
|
2012-03-29 06:22:22 +00:00
|
|
|
static void free_fragment_list(struct fragment *list)
|
2012-03-07 22:21:25 +00:00
|
|
|
{
|
2012-03-29 06:22:22 +00:00
|
|
|
while (list) {
|
|
|
|
struct fragment *next = list->next;
|
|
|
|
if (list->free_patch)
|
|
|
|
free((char *)list->patch);
|
|
|
|
free(list);
|
|
|
|
list = next;
|
2012-03-27 22:10:01 +00:00
|
|
|
}
|
2012-03-29 06:22:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void free_patch(struct patch *patch)
|
|
|
|
{
|
|
|
|
free_fragment_list(patch->fragments);
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->def_name);
|
|
|
|
free(patch->old_name);
|
|
|
|
free(patch->new_name);
|
2012-03-21 22:21:32 +00:00
|
|
|
free(patch->result);
|
2012-03-27 22:10:01 +00:00
|
|
|
free(patch);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_patch_list(struct patch *list)
|
|
|
|
{
|
|
|
|
while (list) {
|
|
|
|
struct patch *next = list->next;
|
|
|
|
free_patch(list);
|
|
|
|
list = next;
|
2012-03-07 22:21:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
/*
|
|
|
|
* A line in a file, len-bytes long (includes the terminating LF,
|
|
|
|
* except for an incomplete line at the end if the file ends with
|
|
|
|
* one), and its contents hashes to 'hash'.
|
|
|
|
*/
|
|
|
|
struct line {
|
|
|
|
size_t len;
|
|
|
|
unsigned hash : 24;
|
|
|
|
unsigned flag : 8;
|
2008-01-29 08:17:55 +00:00
|
|
|
#define LINE_COMMON 1
|
apply: do not patch lines that were already patched
When looking for a place to apply a hunk, we used to check lines that
match the preimage of it, starting from the line that the patch wants to
apply the hunk at, looking forward and backward with increasing offsets
until we find a match.
Colin Guthrie found an interesting case where this misapplied a patch that
wanted to touch a preimage that consists of
}
}
return 0;
}
which is a rather unfortunately common pattern.
The target version of the file originally had only one such location, but
the hunk immediately before that created another instance of such block of
lines, and find_pos() happily reported that the preimage of the hunk
matched what it wanted to modify.
Oops.
By marking the lines application of earlier hunks touched and preventing
match_fragment() from considering them as a match with preimage of other
hunks, we can reduce such an accident.
I also considered to teach apply_one_fragment() to take the offset we have
found while applying the previous hunk into account when looking for a
match with find_pos(), but dismissed that approach, because it would
sometimes work better but sometimes worse, depending on the difference
between the version the patch was created against and the version the
patch is being applied.
This does _not_ prevent misapplication of patches to a file that has many
similar looking blocks of lines and a preimage cannot identify which one
of them should be applied. For that, we would need to scan beyond the
first match in find_pos(), and issue a warning (or error out). That will
be a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-04 20:25:34 +00:00
|
|
|
#define LINE_PATCHED 2
|
2008-01-27 01:42:49 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This represents a "file", which is an array of "lines".
|
|
|
|
*/
|
|
|
|
struct image {
|
|
|
|
char *buf;
|
|
|
|
size_t len;
|
|
|
|
size_t nr;
|
2008-01-29 08:17:55 +00:00
|
|
|
size_t alloc;
|
2008-01-27 01:42:49 +00:00
|
|
|
struct line *line_allocated;
|
|
|
|
struct line *line;
|
|
|
|
};
|
|
|
|
|
|
|
|
static uint32_t hash_line(const char *cp, size_t len)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
uint32_t h;
|
|
|
|
for (i = 0, h = 0; i < len; i++) {
|
|
|
|
if (!isspace(cp[i])) {
|
|
|
|
h = h * 3 + (cp[i] & 0xff);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return h;
|
|
|
|
}
|
|
|
|
|
2009-08-04 11:16:49 +00:00
|
|
|
/*
|
|
|
|
* Compare lines s1 of length n1 and s2 of length n2, ignoring
|
|
|
|
* whitespace difference. Returns 1 if they match, 0 otherwise
|
|
|
|
*/
|
|
|
|
static int fuzzy_matchlines(const char *s1, size_t n1,
|
|
|
|
const char *s2, size_t n2)
|
|
|
|
{
|
|
|
|
const char *last1 = s1 + n1 - 1;
|
|
|
|
const char *last2 = s2 + n2 - 1;
|
|
|
|
int result = 0;
|
|
|
|
|
|
|
|
/* ignore line endings */
|
|
|
|
while ((*last1 == '\r') || (*last1 == '\n'))
|
|
|
|
last1--;
|
|
|
|
while ((*last2 == '\r') || (*last2 == '\n'))
|
|
|
|
last2--;
|
|
|
|
|
apply --ignore-space-change: lines with and without leading whitespaces do not match
The fuzzy_matchlines() function is used when attempting to resurrect
a patch that is whitespace-damaged, or when applying a patch that
was produced against an old codebase to the codebase after
indentation change.
The patch may want to change a line "a_bc" ("_" is used throught
this description for a whitespace to make it stand out) in the
original into something else, and we may not find "a_bc" in the
current source, but there may be "a__bc" (two spaces instead of one
the whitespace-damaged patch claims to expect). By ignoring the
amount of whitespaces, it forces "git apply" to consider that "a_bc"
in the broken patch meant to refer to "a__bc" in reality.
However, the implementation special cases a run of whitespaces at
the beginning of a line and makes "abc" match "_abc", even though a
whitespace in the middle of string never matches a 0-width gap,
e.g. "a_bc" does not match "abc". A run of whitespace at the end of
one string does not match a 0-width end of line on the other line,
either, e.g. "abc_" does not match "abc".
Fix this inconsistency by making the code skip leading whitespaces
only when both strings begin with a whitespace. This makes the
option mean the same as the option of the same name in "diff" and
"git diff".
Note that I am not sure if anybody sane should use this option in
the first place. The fuzzy match logic may be able to find the
original line that the patch author may have meant to touch because
it does not fully trust what the original lines say (i.e. context
lines prefixed by " " and old lines prefixed by "-" does not have to
exactly match the contents the patch is applied to). There is no
reason for us to trust what the replacement lines (i.e. new lines
prefixed by "+") say, either, but with this option enabled, we end
up copying these new lines with suspicious whitespace distributions
literally into the patched result. But as long as we keep it, we
should make it do its insane thing consistently.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-26 20:42:06 +00:00
|
|
|
/* skip leading whitespaces, if both begin with whitespace */
|
|
|
|
if (s1 <= last1 && s2 <= last2 && isspace(*s1) && isspace(*s2)) {
|
|
|
|
while (isspace(*s1) && (s1 <= last1))
|
|
|
|
s1++;
|
|
|
|
while (isspace(*s2) && (s2 <= last2))
|
|
|
|
s2++;
|
|
|
|
}
|
2009-08-04 11:16:49 +00:00
|
|
|
/* early return if both lines are empty */
|
|
|
|
if ((s1 > last1) && (s2 > last2))
|
|
|
|
return 1;
|
|
|
|
while (!result) {
|
|
|
|
result = *s1++ - *s2++;
|
|
|
|
/*
|
|
|
|
* Skip whitespace inside. We check for whitespace on
|
|
|
|
* both buffers because we don't want "a b" to match
|
|
|
|
* "ab"
|
|
|
|
*/
|
|
|
|
if (isspace(*s1) && isspace(*s2)) {
|
|
|
|
while (isspace(*s1) && s1 <= last1)
|
|
|
|
s1++;
|
|
|
|
while (isspace(*s2) && s2 <= last2)
|
|
|
|
s2++;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If we reached the end on one side only,
|
|
|
|
* lines don't match
|
|
|
|
*/
|
|
|
|
if (
|
|
|
|
((s2 > last2) && (s1 <= last1)) ||
|
|
|
|
((s1 > last1) && (s2 <= last2)))
|
|
|
|
return 0;
|
|
|
|
if ((s1 > last1) && (s2 > last2))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return !result;
|
|
|
|
}
|
|
|
|
|
2008-01-29 08:17:55 +00:00
|
|
|
static void add_line_info(struct image *img, const char *bol, size_t len, unsigned flag)
|
|
|
|
{
|
|
|
|
ALLOC_GROW(img->line_allocated, img->nr + 1, img->alloc);
|
|
|
|
img->line_allocated[img->nr].len = len;
|
|
|
|
img->line_allocated[img->nr].hash = hash_line(bol, len);
|
|
|
|
img->line_allocated[img->nr].flag = flag;
|
|
|
|
img->nr++;
|
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* "buf" has the file contents to be patched (read from various sources).
|
|
|
|
* attach it to "image" and add line-based index to it.
|
|
|
|
* "image" now owns the "buf".
|
|
|
|
*/
|
2008-01-27 01:42:49 +00:00
|
|
|
static void prepare_image(struct image *image, char *buf, size_t len,
|
|
|
|
int prepare_linetable)
|
|
|
|
{
|
|
|
|
const char *cp, *ep;
|
|
|
|
|
2008-01-29 08:17:55 +00:00
|
|
|
memset(image, 0, sizeof(*image));
|
2008-01-27 01:42:49 +00:00
|
|
|
image->buf = buf;
|
|
|
|
image->len = len;
|
|
|
|
|
2008-01-29 08:17:55 +00:00
|
|
|
if (!prepare_linetable)
|
2008-01-27 01:42:49 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
ep = image->buf + image->len;
|
|
|
|
cp = image->buf;
|
|
|
|
while (cp < ep) {
|
|
|
|
const char *next;
|
|
|
|
for (next = cp; next < ep && *next != '\n'; next++)
|
|
|
|
;
|
|
|
|
if (next < ep)
|
|
|
|
next++;
|
2008-01-29 08:17:55 +00:00
|
|
|
add_line_info(image, cp, next - cp, 0);
|
2008-01-27 01:42:49 +00:00
|
|
|
cp = next;
|
|
|
|
}
|
2008-01-29 08:17:55 +00:00
|
|
|
image->line = image->line_allocated;
|
2008-01-27 01:42:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void clear_image(struct image *image)
|
|
|
|
{
|
|
|
|
free(image->buf);
|
2012-05-08 21:38:06 +00:00
|
|
|
free(image->line_allocated);
|
|
|
|
memset(image, 0, sizeof(*image));
|
2008-01-27 01:42:49 +00:00
|
|
|
}
|
|
|
|
|
2012-04-23 12:30:28 +00:00
|
|
|
/* fmt must contain _one_ %s and no other substitution */
|
|
|
|
static void say_patch_name(FILE *output, const char *fmt, struct patch *patch)
|
2006-08-18 10:14:48 +00:00
|
|
|
{
|
2012-04-23 12:30:28 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
2006-08-18 10:14:48 +00:00
|
|
|
if (patch->old_name && patch->new_name &&
|
|
|
|
strcmp(patch->old_name, patch->new_name)) {
|
2012-04-23 12:30:28 +00:00
|
|
|
quote_c_style(patch->old_name, &sb, NULL, 0);
|
|
|
|
strbuf_addstr(&sb, " => ");
|
|
|
|
quote_c_style(patch->new_name, &sb, NULL, 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
|
|
|
} else {
|
2006-08-18 10:14:48 +00:00
|
|
|
const char *n = patch->new_name;
|
|
|
|
if (!n)
|
|
|
|
n = patch->old_name;
|
2012-04-23 12:30:28 +00:00
|
|
|
quote_c_style(n, &sb, NULL, 0);
|
2006-08-18 10:14:48 +00:00
|
|
|
}
|
2012-04-23 12:30:28 +00:00
|
|
|
fprintf(output, fmt, sb.buf);
|
|
|
|
fputc('\n', output);
|
|
|
|
strbuf_release(&sb);
|
2006-08-18 10:14:48 +00:00
|
|
|
}
|
|
|
|
|
2005-05-23 23:09:09 +00:00
|
|
|
#define SLOP (16)
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2016-08-08 21:03:01 +00:00
|
|
|
static int read_patch_file(struct strbuf *sb, int fd)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2007-09-27 11:33:19 +00:00
|
|
|
if (strbuf_read(sb, fd, 0) < 0)
|
2016-08-08 21:03:01 +00:00
|
|
|
return error_errno("git apply: failed to read");
|
2005-05-23 23:09:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure that we have some slop in the buffer
|
|
|
|
* so that we can do speculative "memcmp" etc, and
|
|
|
|
* see to it that it is NUL-filled.
|
|
|
|
*/
|
2007-09-27 11:33:19 +00:00
|
|
|
strbuf_grow(sb, SLOP);
|
|
|
|
memset(sb->buf + sb->len, 0, SLOP);
|
2016-08-08 21:03:01 +00:00
|
|
|
return 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
|
2005-06-05 18:03:13 +00:00
|
|
|
static unsigned long linelen(const char *buffer, unsigned long size)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
|
|
|
unsigned long len = 0;
|
|
|
|
while (size--) {
|
|
|
|
len++;
|
|
|
|
if (*buffer++ == '\n')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
2005-05-23 23:09:09 +00:00
|
|
|
static int is_dev_null(const char *str)
|
|
|
|
{
|
2014-10-04 18:54:50 +00:00
|
|
|
return skip_prefix(str, "/dev/null", &str) && isspace(*str);
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2005-05-31 22:05:59 +00:00
|
|
|
#define TERM_SPACE 1
|
|
|
|
#define TERM_TAB 2
|
2005-05-24 02:13:55 +00:00
|
|
|
|
2016-05-28 16:12:01 +00:00
|
|
|
static int name_terminate(int c, int terminate)
|
2005-05-24 02:13:55 +00:00
|
|
|
{
|
|
|
|
if (c == ' ' && !(terminate & TERM_SPACE))
|
|
|
|
return 0;
|
|
|
|
if (c == '\t' && !(terminate & TERM_TAB))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-05-21 12:25:11 +00:00
|
|
|
/* remove double slashes to make --index work with such filenames */
|
|
|
|
static char *squash_slash(char *name)
|
|
|
|
{
|
|
|
|
int i = 0, j = 0;
|
|
|
|
|
2010-01-17 02:05:10 +00:00
|
|
|
if (!name)
|
|
|
|
return NULL;
|
|
|
|
|
2009-05-21 12:25:11 +00:00
|
|
|
while (name[i]) {
|
|
|
|
if ((name[j++] = name[i++]) == '/')
|
|
|
|
while (name[i] == '/')
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
name[j] = '\0';
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
static char *find_name_gnu(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
const char *def,
|
|
|
|
int p_value)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2010-08-19 01:46:46 +00:00
|
|
|
struct strbuf name = STRBUF_INIT;
|
|
|
|
char *cp;
|
2010-01-17 02:05:10 +00:00
|
|
|
|
2010-08-19 01:46:46 +00:00
|
|
|
/*
|
|
|
|
* Proposed "new-style" GNU patch/diff format; see
|
2013-07-22 08:02:17 +00:00
|
|
|
* http://marc.info/?l=git&m=112927316408690&w=2
|
2010-08-19 01:46:46 +00:00
|
|
|
*/
|
|
|
|
if (unquote_c_style(&name, line, NULL)) {
|
|
|
|
strbuf_release(&name);
|
|
|
|
return NULL;
|
|
|
|
}
|
2007-09-19 22:42:14 +00:00
|
|
|
|
2010-08-19 01:46:46 +00:00
|
|
|
for (cp = name.buf; p_value; p_value--) {
|
|
|
|
cp = strchr(cp, '/');
|
|
|
|
if (!cp) {
|
|
|
|
strbuf_release(&name);
|
|
|
|
return NULL;
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
2010-08-19 01:46:46 +00:00
|
|
|
cp++;
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_remove(&name, 0, cp - name.buf);
|
2016-05-24 08:11:11 +00:00
|
|
|
if (state->root.len)
|
|
|
|
strbuf_insert(&name, 0, state->root.buf, state->root.len);
|
2010-08-19 01:46:46 +00:00
|
|
|
return squash_slash(strbuf_detach(&name, NULL));
|
|
|
|
}
|
|
|
|
|
2010-09-29 21:41:08 +00:00
|
|
|
static size_t sane_tz_len(const char *line, size_t len)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2010-08-19 01:50:14 +00:00
|
|
|
const char *tz, *p;
|
2010-01-17 02:05:10 +00:00
|
|
|
|
2010-08-19 01:50:14 +00:00
|
|
|
if (len < strlen(" +0500") || line[len-strlen(" +0500")] != ' ')
|
|
|
|
return 0;
|
|
|
|
tz = line + len - strlen(" +0500");
|
|
|
|
|
|
|
|
if (tz[1] != '+' && tz[1] != '-')
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (p = tz + 2; p != line + len; p++)
|
|
|
|
if (!isdigit(*p))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return line + len - tz;
|
|
|
|
}
|
|
|
|
|
2010-09-29 21:41:08 +00:00
|
|
|
static size_t tz_with_colon_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *tz, *p;
|
|
|
|
|
|
|
|
if (len < strlen(" +08:00") || line[len - strlen(":00")] != ':')
|
|
|
|
return 0;
|
|
|
|
tz = line + len - strlen(" +08:00");
|
|
|
|
|
|
|
|
if (tz[0] != ' ' || (tz[1] != '+' && tz[1] != '-'))
|
|
|
|
return 0;
|
|
|
|
p = tz + 2;
|
|
|
|
if (!isdigit(*p++) || !isdigit(*p++) || *p++ != ':' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return line + len - tz;
|
|
|
|
}
|
|
|
|
|
2010-08-19 01:50:14 +00:00
|
|
|
static size_t date_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *date, *p;
|
|
|
|
|
|
|
|
if (len < strlen("72-02-05") || line[len-strlen("-05")] != '-')
|
|
|
|
return 0;
|
|
|
|
p = date = line + len - strlen("72-02-05");
|
|
|
|
|
|
|
|
if (!isdigit(*p++) || !isdigit(*p++) || *p++ != '-' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++) || *p++ != '-' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++)) /* Not a date. */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (date - line >= strlen("19") &&
|
|
|
|
isdigit(date[-1]) && isdigit(date[-2])) /* 4-digit year */
|
|
|
|
date -= strlen("19");
|
|
|
|
|
|
|
|
return line + len - date;
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t short_time_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *time, *p;
|
|
|
|
|
|
|
|
if (len < strlen(" 07:01:32") || line[len-strlen(":32")] != ':')
|
|
|
|
return 0;
|
|
|
|
p = time = line + len - strlen(" 07:01:32");
|
|
|
|
|
|
|
|
/* Permit 1-digit hours? */
|
|
|
|
if (*p++ != ' ' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++) || *p++ != ':' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++) || *p++ != ':' ||
|
|
|
|
!isdigit(*p++) || !isdigit(*p++)) /* Not a time. */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return line + len - time;
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t fractional_time_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *p;
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
/* Expected format: 19:41:17.620000023 */
|
|
|
|
if (!len || !isdigit(line[len - 1]))
|
|
|
|
return 0;
|
|
|
|
p = line + len - 1;
|
|
|
|
|
|
|
|
/* Fractional seconds. */
|
|
|
|
while (p > line && isdigit(*p))
|
|
|
|
p--;
|
|
|
|
if (*p != '.')
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Hours, minutes, and whole seconds. */
|
|
|
|
n = short_time_len(line, p - line);
|
|
|
|
if (!n)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return line + len - p + n;
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t trailing_spaces_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *p;
|
|
|
|
|
|
|
|
/* Expected format: ' ' x (1 or more) */
|
|
|
|
if (!len || line[len - 1] != ' ')
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
p = line + len;
|
|
|
|
while (p != line) {
|
|
|
|
p--;
|
|
|
|
if (*p != ' ')
|
|
|
|
return line + len - (p + 1);
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
|
|
|
|
2010-08-19 01:50:14 +00:00
|
|
|
/* All spaces! */
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t diff_timestamp_len(const char *line, size_t len)
|
|
|
|
{
|
|
|
|
const char *end = line + len;
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Posix: 2010-07-05 19:41:17
|
|
|
|
* GNU: 2010-07-05 19:41:17.620000023 -0500
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!isdigit(end[-1]))
|
|
|
|
return 0;
|
|
|
|
|
2010-09-29 21:41:08 +00:00
|
|
|
n = sane_tz_len(line, end - line);
|
|
|
|
if (!n)
|
|
|
|
n = tz_with_colon_len(line, end - line);
|
2010-08-19 01:50:14 +00:00
|
|
|
end -= n;
|
|
|
|
|
|
|
|
n = short_time_len(line, end - line);
|
|
|
|
if (!n)
|
|
|
|
n = fractional_time_len(line, end - line);
|
|
|
|
end -= n;
|
|
|
|
|
|
|
|
n = date_len(line, end - line);
|
|
|
|
if (!n) /* No date. Too bad. */
|
|
|
|
return 0;
|
|
|
|
end -= n;
|
|
|
|
|
|
|
|
if (end == line) /* No space before date. */
|
|
|
|
return 0;
|
|
|
|
if (end[-1] == '\t') { /* Success! */
|
|
|
|
end--;
|
|
|
|
return line + len - end;
|
|
|
|
}
|
|
|
|
if (end[-1] != ' ') /* No space before date. */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Whitespace damage. */
|
|
|
|
end -= trailing_spaces_len(line, end - line);
|
|
|
|
return line + len - end;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
static char *find_name_common(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
const char *def,
|
|
|
|
int p_value,
|
|
|
|
const char *end,
|
|
|
|
int terminate)
|
2010-08-19 01:50:14 +00:00
|
|
|
{
|
|
|
|
int len;
|
|
|
|
const char *start = NULL;
|
|
|
|
|
2010-08-19 01:46:46 +00:00
|
|
|
if (p_value == 0)
|
|
|
|
start = line;
|
2010-08-19 01:50:14 +00:00
|
|
|
while (line != end) {
|
2005-05-23 23:09:09 +00:00
|
|
|
char c = *line;
|
2005-05-24 02:13:55 +00:00
|
|
|
|
2010-08-19 01:50:14 +00:00
|
|
|
if (!end && isspace(c)) {
|
2005-05-24 02:13:55 +00:00
|
|
|
if (c == '\n')
|
|
|
|
break;
|
2016-05-28 16:12:01 +00:00
|
|
|
if (name_terminate(c, terminate))
|
2005-05-24 02:13:55 +00:00
|
|
|
break;
|
|
|
|
}
|
2005-05-23 23:09:09 +00:00
|
|
|
line++;
|
|
|
|
if (c == '/' && !--p_value)
|
|
|
|
start = line;
|
|
|
|
}
|
|
|
|
if (!start)
|
2015-01-13 01:58:15 +00:00
|
|
|
return squash_slash(xstrdup_or_null(def));
|
2005-05-23 23:09:09 +00:00
|
|
|
len = line - start;
|
|
|
|
if (!len)
|
2015-01-13 01:58:15 +00:00
|
|
|
return squash_slash(xstrdup_or_null(def));
|
2005-05-23 23:09:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generally we prefer the shorter name, especially
|
|
|
|
* if the other one is just a variation of that with
|
|
|
|
* something else tacked on to the end (ie "file.orig"
|
|
|
|
* or "file~").
|
|
|
|
*/
|
|
|
|
if (def) {
|
|
|
|
int deflen = strlen(def);
|
|
|
|
if (deflen < len && !strncmp(start, def, deflen))
|
2012-03-21 22:18:18 +00:00
|
|
|
return squash_slash(xstrdup(def));
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
2005-05-23 23:09:09 +00:00
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
if (state->root.len) {
|
|
|
|
char *ret = xstrfmt("%s%.*s", state->root.buf, len, start);
|
2009-05-21 12:25:11 +00:00
|
|
|
return squash_slash(ret);
|
2008-06-30 23:44:47 +00:00
|
|
|
}
|
|
|
|
|
2009-05-21 12:25:11 +00:00
|
|
|
return squash_slash(xmemdupz(start, len));
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
static char *find_name(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
char *def,
|
|
|
|
int p_value,
|
|
|
|
int terminate)
|
2010-08-19 01:50:14 +00:00
|
|
|
{
|
|
|
|
if (*line == '"') {
|
2016-05-24 08:11:11 +00:00
|
|
|
char *name = find_name_gnu(state, line, def, p_value);
|
2010-08-19 01:50:14 +00:00
|
|
|
if (name)
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
return find_name_common(state, line, def, p_value, NULL, terminate);
|
2010-08-19 01:50:14 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
static char *find_name_traditional(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
char *def,
|
|
|
|
int p_value)
|
2010-08-19 01:50:14 +00:00
|
|
|
{
|
2013-07-18 21:35:27 +00:00
|
|
|
size_t len;
|
2010-08-19 01:50:14 +00:00
|
|
|
size_t date_len;
|
|
|
|
|
|
|
|
if (*line == '"') {
|
2016-05-24 08:11:11 +00:00
|
|
|
char *name = find_name_gnu(state, line, def, p_value);
|
2010-08-19 01:50:14 +00:00
|
|
|
if (name)
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
|
|
|
len = strchrnul(line, '\n') - line;
|
|
|
|
date_len = diff_timestamp_len(line, len);
|
|
|
|
if (!date_len)
|
2016-05-24 08:11:11 +00:00
|
|
|
return find_name_common(state, line, def, p_value, NULL, TERM_TAB);
|
2010-08-19 01:50:14 +00:00
|
|
|
len -= date_len;
|
|
|
|
|
2016-05-24 08:11:11 +00:00
|
|
|
return find_name_common(state, line, def, p_value, line + len, 0);
|
2010-08-19 01:50:14 +00:00
|
|
|
}
|
|
|
|
|
2007-02-22 00:05:56 +00:00
|
|
|
static int count_slashes(const char *cp)
|
|
|
|
{
|
|
|
|
int cnt = 0;
|
|
|
|
char ch;
|
|
|
|
|
|
|
|
while ((ch = *cp++))
|
|
|
|
if (ch == '/')
|
|
|
|
cnt++;
|
|
|
|
return cnt;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Given the string after "--- " or "+++ ", guess the appropriate
|
|
|
|
* p_value for the given patch.
|
|
|
|
*/
|
2016-05-11 13:16:19 +00:00
|
|
|
static int guess_p_value(struct apply_state *state, const char *nameline)
|
2007-02-22 00:05:56 +00:00
|
|
|
{
|
|
|
|
char *name, *cp;
|
|
|
|
int val = -1;
|
|
|
|
|
|
|
|
if (is_dev_null(nameline))
|
|
|
|
return -1;
|
2016-05-24 08:11:11 +00:00
|
|
|
name = find_name_traditional(state, nameline, NULL, 0);
|
2007-02-22 00:05:56 +00:00
|
|
|
if (!name)
|
|
|
|
return -1;
|
|
|
|
cp = strchr(name, '/');
|
|
|
|
if (!cp)
|
|
|
|
val = 0;
|
2016-05-11 13:16:19 +00:00
|
|
|
else if (state->prefix) {
|
2007-02-22 00:05:56 +00:00
|
|
|
/*
|
|
|
|
* Does it begin with "a/$our-prefix" and such? Then this is
|
|
|
|
* very likely to apply to our directory.
|
|
|
|
*/
|
2016-05-11 13:16:19 +00:00
|
|
|
if (!strncmp(name, state->prefix, state->prefix_length))
|
|
|
|
val = count_slashes(state->prefix);
|
2007-02-22 00:05:56 +00:00
|
|
|
else {
|
|
|
|
cp++;
|
2016-05-11 13:16:19 +00:00
|
|
|
if (!strncmp(cp, state->prefix, state->prefix_length))
|
|
|
|
val = count_slashes(state->prefix) + 1;
|
2007-02-22 00:05:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
free(name);
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2009-07-11 01:38:08 +00:00
|
|
|
/*
|
2015-09-09 13:33:18 +00:00
|
|
|
* Does the ---/+++ line have the POSIX timestamp after the last HT?
|
2009-07-11 01:38:08 +00:00
|
|
|
* GNU diff puts epoch there to signal a creation/deletion event. Is
|
|
|
|
* this such a timestamp?
|
|
|
|
*/
|
|
|
|
static int has_epoch_timestamp(const char *nameline)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We are only interested in epoch timestamp; any non-zero
|
|
|
|
* fraction cannot be one, hence "(\.0+)?" in the regexp below.
|
|
|
|
* For the same reason, the date must be either 1969-12-31 or
|
|
|
|
* 1970-01-01, and the seconds part must be "00".
|
|
|
|
*/
|
|
|
|
const char stamp_regexp[] =
|
|
|
|
"^(1969-12-31|1970-01-01)"
|
|
|
|
" "
|
|
|
|
"[0-2][0-9]:[0-5][0-9]:00(\\.0+)?"
|
|
|
|
" "
|
2010-09-29 20:49:49 +00:00
|
|
|
"([-+][0-2][0-9]:?[0-5][0-9])\n";
|
|
|
|
const char *timestamp = NULL, *cp, *colon;
|
2009-07-11 01:38:08 +00:00
|
|
|
static regex_t *stamp;
|
|
|
|
regmatch_t m[10];
|
|
|
|
int zoneoffset;
|
|
|
|
int hourminute;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
for (cp = nameline; *cp != '\n'; cp++) {
|
|
|
|
if (*cp == '\t')
|
|
|
|
timestamp = cp + 1;
|
|
|
|
}
|
|
|
|
if (!timestamp)
|
|
|
|
return 0;
|
|
|
|
if (!stamp) {
|
|
|
|
stamp = xmalloc(sizeof(*stamp));
|
|
|
|
if (regcomp(stamp, stamp_regexp, REG_EXTENDED)) {
|
2012-04-23 12:30:27 +00:00
|
|
|
warning(_("Cannot prepare timestamp regexp %s"),
|
2009-07-11 01:38:08 +00:00
|
|
|
stamp_regexp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
status = regexec(stamp, timestamp, ARRAY_SIZE(m), m, 0);
|
|
|
|
if (status) {
|
|
|
|
if (status != REG_NOMATCH)
|
2012-04-23 12:30:27 +00:00
|
|
|
warning(_("regexec returned %d for input: %s"),
|
2009-07-11 01:38:08 +00:00
|
|
|
status, timestamp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-09-29 20:49:49 +00:00
|
|
|
zoneoffset = strtol(timestamp + m[3].rm_so + 1, (char **) &colon, 10);
|
|
|
|
if (*colon == ':')
|
|
|
|
zoneoffset = zoneoffset * 60 + strtol(colon + 1, NULL, 10);
|
|
|
|
else
|
|
|
|
zoneoffset = (zoneoffset / 100) * 60 + (zoneoffset % 100);
|
2009-07-11 01:38:08 +00:00
|
|
|
if (timestamp[m[3].rm_so] == '-')
|
|
|
|
zoneoffset = -zoneoffset;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* YYYY-MM-DD hh:mm:ss must be from either 1969-12-31
|
|
|
|
* (west of GMT) or 1970-01-01 (east of GMT)
|
|
|
|
*/
|
|
|
|
if ((zoneoffset < 0 && memcmp(timestamp, "1969-12-31", 10)) ||
|
|
|
|
(0 <= zoneoffset && memcmp(timestamp, "1970-01-01", 10)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
hourminute = (strtol(timestamp + 11, NULL, 10) * 60 +
|
|
|
|
strtol(timestamp + 14, NULL, 10) -
|
|
|
|
zoneoffset);
|
|
|
|
|
|
|
|
return ((zoneoffset < 0 && hourminute == 1440) ||
|
|
|
|
(0 <= zoneoffset && !hourminute));
|
|
|
|
}
|
|
|
|
|
2005-05-23 23:09:09 +00:00
|
|
|
/*
|
2008-05-17 08:46:47 +00:00
|
|
|
* Get the name etc info from the ---/+++ lines of a traditional patch header
|
2005-05-23 23:09:09 +00:00
|
|
|
*
|
2005-05-24 02:13:55 +00:00
|
|
|
* FIXME! The end-of-filename heuristics are kind of screwy. For existing
|
|
|
|
* files, we can happily check the index for a match, but for creating a
|
|
|
|
* new file we should try to match whatever "patch" does. I have no idea.
|
2005-05-23 23:09:09 +00:00
|
|
|
*/
|
2016-08-08 21:03:12 +00:00
|
|
|
static int parse_traditional_patch(struct apply_state *state,
|
|
|
|
const char *first,
|
|
|
|
const char *second,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
|
|
|
char *name;
|
|
|
|
|
2006-07-10 06:57:51 +00:00
|
|
|
first += 4; /* skip "--- " */
|
|
|
|
second += 4; /* skip "+++ " */
|
2016-05-24 08:11:10 +00:00
|
|
|
if (!state->p_value_known) {
|
2007-02-22 00:05:56 +00:00
|
|
|
int p, q;
|
2016-05-11 13:16:19 +00:00
|
|
|
p = guess_p_value(state, first);
|
|
|
|
q = guess_p_value(state, second);
|
2007-02-22 00:05:56 +00:00
|
|
|
if (p < 0) p = q;
|
|
|
|
if (0 <= p && p == q) {
|
2016-05-24 08:11:09 +00:00
|
|
|
state->p_value = p;
|
2016-05-24 08:11:10 +00:00
|
|
|
state->p_value_known = 1;
|
2007-02-22 00:05:56 +00:00
|
|
|
}
|
|
|
|
}
|
2005-05-23 23:09:09 +00:00
|
|
|
if (is_dev_null(first)) {
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_new = 1;
|
|
|
|
patch->is_delete = 0;
|
2016-05-24 08:11:11 +00:00
|
|
|
name = find_name_traditional(state, second, NULL, state->p_value);
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->new_name = name;
|
2005-05-23 23:09:09 +00:00
|
|
|
} else if (is_dev_null(second)) {
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_new = 0;
|
|
|
|
patch->is_delete = 1;
|
2016-05-24 08:11:11 +00:00
|
|
|
name = find_name_traditional(state, first, NULL, state->p_value);
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->old_name = name;
|
2005-05-23 23:09:09 +00:00
|
|
|
} else {
|
2012-03-21 22:18:18 +00:00
|
|
|
char *first_name;
|
2016-05-24 08:11:11 +00:00
|
|
|
first_name = find_name_traditional(state, first, NULL, state->p_value);
|
|
|
|
name = find_name_traditional(state, second, first_name, state->p_value);
|
2012-03-21 22:18:18 +00:00
|
|
|
free(first_name);
|
2009-07-11 01:38:08 +00:00
|
|
|
if (has_epoch_timestamp(first)) {
|
|
|
|
patch->is_new = 1;
|
|
|
|
patch->is_delete = 0;
|
|
|
|
patch->new_name = name;
|
|
|
|
} else if (has_epoch_timestamp(second)) {
|
|
|
|
patch->is_new = 0;
|
|
|
|
patch->is_delete = 1;
|
|
|
|
patch->old_name = name;
|
|
|
|
} else {
|
2012-03-21 22:18:18 +00:00
|
|
|
patch->old_name = name;
|
2015-01-13 01:58:15 +00:00
|
|
|
patch->new_name = xstrdup_or_null(name);
|
2009-07-11 01:38:08 +00:00
|
|
|
}
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
if (!name)
|
2016-08-08 21:03:12 +00:00
|
|
|
return error(_("unable to find filename in patch at line %d"), state->linenr);
|
|
|
|
|
|
|
|
return 0;
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_hdrend(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2016-08-08 21:03:13 +00:00
|
|
|
return 1;
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2005-05-24 02:54:55 +00:00
|
|
|
/*
|
|
|
|
* We're anal about diff header consistency, to make
|
|
|
|
* sure that we don't end up having strange ambiguous
|
|
|
|
* patches floating around.
|
|
|
|
*
|
|
|
|
* As a result, gitdiff_{old|new}name() will check
|
|
|
|
* their names against any previous information, just
|
|
|
|
* to make sure..
|
|
|
|
*/
|
2012-05-06 13:13:22 +00:00
|
|
|
#define DIFF_OLD_NAME 0
|
|
|
|
#define DIFF_NEW_NAME 1
|
|
|
|
|
2016-08-08 21:03:14 +00:00
|
|
|
static int gitdiff_verify_name(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
int isnull,
|
|
|
|
char **name,
|
|
|
|
int side)
|
2005-05-24 02:54:55 +00:00
|
|
|
{
|
2016-05-11 13:16:12 +00:00
|
|
|
if (!*name && !isnull) {
|
2016-05-24 08:11:11 +00:00
|
|
|
*name = find_name(state, line, NULL, state->p_value, TERM_TAB);
|
2016-08-08 21:03:14 +00:00
|
|
|
return 0;
|
2016-05-11 13:16:12 +00:00
|
|
|
}
|
2005-05-24 02:54:55 +00:00
|
|
|
|
2016-05-11 13:16:12 +00:00
|
|
|
if (*name) {
|
|
|
|
int len = strlen(*name);
|
2005-10-15 04:54:52 +00:00
|
|
|
char *another;
|
2005-05-24 02:54:55 +00:00
|
|
|
if (isnull)
|
2016-08-08 21:03:14 +00:00
|
|
|
return error(_("git apply: bad git-diff - expected /dev/null, got %s on line %d"),
|
|
|
|
*name, state->linenr);
|
2016-05-24 08:11:11 +00:00
|
|
|
another = find_name(state, line, NULL, state->p_value, TERM_TAB);
|
2016-08-08 21:03:14 +00:00
|
|
|
if (!another || memcmp(another, *name, len + 1)) {
|
|
|
|
free(another);
|
|
|
|
return error((side == DIFF_NEW_NAME) ?
|
2012-05-06 13:13:22 +00:00
|
|
|
_("git apply: bad git-diff - inconsistent new filename on line %d") :
|
2016-05-24 08:11:20 +00:00
|
|
|
_("git apply: bad git-diff - inconsistent old filename on line %d"), state->linenr);
|
2016-08-08 21:03:14 +00:00
|
|
|
}
|
2005-10-15 04:54:52 +00:00
|
|
|
free(another);
|
2016-03-22 20:58:40 +00:00
|
|
|
} else {
|
2005-10-15 04:54:52 +00:00
|
|
|
/* expect "/dev/null" */
|
|
|
|
if (memcmp("/dev/null", line, 9) || line[9] != '\n')
|
2016-08-08 21:03:14 +00:00
|
|
|
return error(_("git apply: bad git-diff - expected /dev/null on line %d"), state->linenr);
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
2016-08-08 21:03:14 +00:00
|
|
|
|
|
|
|
return 0;
|
2005-05-24 02:54:55 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_oldname(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2016-08-08 21:03:14 +00:00
|
|
|
return gitdiff_verify_name(state, line,
|
|
|
|
patch->is_new, &patch->old_name,
|
|
|
|
DIFF_OLD_NAME);
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_newname(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2016-08-08 21:03:14 +00:00
|
|
|
return gitdiff_verify_name(state, line,
|
|
|
|
patch->is_delete, &patch->new_name,
|
|
|
|
DIFF_NEW_NAME);
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_oldmode(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->old_mode = strtoul(line, NULL, 8);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_newmode(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->new_mode = strtoul(line, NULL, 8);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_delete(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_delete = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->old_name);
|
2015-01-13 01:58:15 +00:00
|
|
|
patch->old_name = xstrdup_or_null(patch->def_name);
|
2016-05-24 08:11:09 +00:00
|
|
|
return gitdiff_oldmode(state, line, patch);
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_newfile(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_new = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->new_name);
|
2015-01-13 01:58:15 +00:00
|
|
|
patch->new_name = xstrdup_or_null(patch->def_name);
|
2016-05-24 08:11:09 +00:00
|
|
|
return gitdiff_newmode(state, line, patch);
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_copysrc(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_copy = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->old_name);
|
2016-05-24 08:11:11 +00:00
|
|
|
patch->old_name = find_name(state, line, NULL, state->p_value ? state->p_value - 1 : 0, 0);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_copydst(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_copy = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->new_name);
|
2016-05-24 08:11:11 +00:00
|
|
|
patch->new_name = find_name(state, line, NULL, state->p_value ? state->p_value - 1 : 0, 0);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_renamesrc(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_rename = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->old_name);
|
2016-05-24 08:11:11 +00:00
|
|
|
patch->old_name = find_name(state, line, NULL, state->p_value ? state->p_value - 1 : 0, 0);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_renamedst(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_rename = 1;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->new_name);
|
2016-05-24 08:11:11 +00:00
|
|
|
patch->new_name = find_name(state, line, NULL, state->p_value ? state->p_value - 1 : 0, 0);
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_similarity(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-23 23:09:09 +00:00
|
|
|
{
|
2013-02-03 14:37:11 +00:00
|
|
|
unsigned long val = strtoul(line, NULL, 10);
|
|
|
|
if (val <= 100)
|
|
|
|
patch->score = val;
|
2005-05-23 23:09:09 +00:00
|
|
|
return 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_dissimilarity(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-30 23:40:16 +00:00
|
|
|
{
|
2013-02-03 14:37:11 +00:00
|
|
|
unsigned long val = strtoul(line, NULL, 10);
|
|
|
|
if (val <= 100)
|
|
|
|
patch->score = val;
|
2005-05-30 23:40:16 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_index(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-10-07 10:42:00 +00:00
|
|
|
{
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* index line is N hexadecimal, "..", N hexadecimal,
|
2005-10-07 10:42:00 +00:00
|
|
|
* and optional space with octal mode.
|
|
|
|
*/
|
|
|
|
const char *ptr, *eol;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
ptr = strchr(line, '.');
|
2005-11-15 01:15:07 +00:00
|
|
|
if (!ptr || ptr[1] != '.' || 40 < ptr - line)
|
2005-10-07 10:42:00 +00:00
|
|
|
return 0;
|
|
|
|
len = ptr - line;
|
|
|
|
memcpy(patch->old_sha1_prefix, line, len);
|
|
|
|
patch->old_sha1_prefix[len] = 0;
|
|
|
|
|
|
|
|
line = ptr + 2;
|
|
|
|
ptr = strchr(line, ' ');
|
2014-07-24 04:43:23 +00:00
|
|
|
eol = strchrnul(line, '\n');
|
2005-10-07 10:42:00 +00:00
|
|
|
|
|
|
|
if (!ptr || eol < ptr)
|
|
|
|
ptr = eol;
|
|
|
|
len = ptr - line;
|
|
|
|
|
2005-11-15 01:15:07 +00:00
|
|
|
if (40 < len)
|
2005-10-07 10:42:00 +00:00
|
|
|
return 0;
|
|
|
|
memcpy(patch->new_sha1_prefix, line, len);
|
|
|
|
patch->new_sha1_prefix[len] = 0;
|
|
|
|
if (*ptr == ' ')
|
2009-01-02 10:55:37 +00:00
|
|
|
patch->old_mode = strtoul(ptr+1, NULL, 8);
|
2005-10-07 10:42:00 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-05-24 02:13:55 +00:00
|
|
|
/*
|
|
|
|
* This is normal for a diff that doesn't change anything: we'll fall through
|
|
|
|
* into the next diff. Tell the parser to break out.
|
|
|
|
*/
|
2016-05-24 08:11:09 +00:00
|
|
|
static int gitdiff_unrecognized(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
struct patch *patch)
|
2005-05-24 02:13:55 +00:00
|
|
|
{
|
2016-08-08 21:03:13 +00:00
|
|
|
return 1;
|
2005-05-24 02:13:55 +00:00
|
|
|
}
|
|
|
|
|
2012-08-25 05:48:55 +00:00
|
|
|
/*
|
|
|
|
* Skip p_value leading components from "line"; as we do not accept
|
|
|
|
* absolute paths, return NULL in that case.
|
|
|
|
*/
|
2016-05-24 08:11:09 +00:00
|
|
|
static const char *skip_tree_prefix(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
int llen)
|
2005-10-15 04:54:52 +00:00
|
|
|
{
|
2012-08-25 05:48:55 +00:00
|
|
|
int nslash;
|
2005-10-15 04:54:52 +00:00
|
|
|
int i;
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
if (!state->p_value)
|
2012-08-25 05:48:55 +00:00
|
|
|
return (llen && line[0] == '/') ? NULL : line;
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
nslash = state->p_value;
|
2005-10-15 04:54:52 +00:00
|
|
|
for (i = 0; i < llen; i++) {
|
|
|
|
int ch = line[i];
|
2009-11-25 10:56:54 +00:00
|
|
|
if (ch == '/' && --nslash <= 0)
|
2012-08-25 05:48:55 +00:00
|
|
|
return (i == 0) ? NULL : &line[i + 1];
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* This is to extract the same name that appears on "diff --git"
|
2005-10-15 04:54:52 +00:00
|
|
|
* line. We do not find and return anything if it is a rename
|
|
|
|
* patch, and it is OK because we will find the name elsewhere.
|
|
|
|
* We need to reliably find name only when it is mode-change only,
|
|
|
|
* creation or deletion of an empty file. In any of these cases,
|
|
|
|
* both sides are the same name under a/ and b/ respectively.
|
|
|
|
*/
|
2016-05-24 08:11:09 +00:00
|
|
|
static char *git_header_name(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
int llen)
|
2005-05-26 20:11:24 +00:00
|
|
|
{
|
2005-10-15 04:54:52 +00:00
|
|
|
const char *name;
|
|
|
|
const char *second = NULL;
|
2010-10-21 22:12:02 +00:00
|
|
|
size_t len, line_len;
|
2005-05-26 20:11:24 +00:00
|
|
|
|
2005-10-15 04:54:52 +00:00
|
|
|
line += strlen("diff --git ");
|
|
|
|
llen -= strlen("diff --git ");
|
|
|
|
|
|
|
|
if (*line == '"') {
|
|
|
|
const char *cp;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf first = STRBUF_INIT;
|
|
|
|
struct strbuf sp = STRBUF_INIT;
|
2007-09-19 22:42:14 +00:00
|
|
|
|
|
|
|
if (unquote_c_style(&first, line, &second))
|
|
|
|
goto free_and_fail1;
|
2005-10-15 04:54:52 +00:00
|
|
|
|
2012-08-25 05:48:55 +00:00
|
|
|
/* strip the a/b prefix including trailing slash */
|
2016-05-24 08:11:09 +00:00
|
|
|
cp = skip_tree_prefix(state, first.buf, first.len);
|
2012-08-25 05:48:55 +00:00
|
|
|
if (!cp)
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail1;
|
2012-08-25 05:48:55 +00:00
|
|
|
strbuf_remove(&first, 0, cp - first.buf);
|
2005-10-15 04:54:52 +00:00
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* second points at one past closing dq of name.
|
2005-10-15 04:54:52 +00:00
|
|
|
* find the second name.
|
|
|
|
*/
|
|
|
|
while ((second < line + llen) && isspace(*second))
|
|
|
|
second++;
|
|
|
|
|
|
|
|
if (line + llen <= second)
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail1;
|
2005-10-15 04:54:52 +00:00
|
|
|
if (*second == '"') {
|
2007-09-19 22:42:14 +00:00
|
|
|
if (unquote_c_style(&sp, second, NULL))
|
|
|
|
goto free_and_fail1;
|
2016-05-24 08:11:09 +00:00
|
|
|
cp = skip_tree_prefix(state, sp.buf, sp.len);
|
2012-08-25 05:48:55 +00:00
|
|
|
if (!cp)
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail1;
|
2005-10-15 04:54:52 +00:00
|
|
|
/* They must match, otherwise ignore */
|
2012-08-25 05:48:55 +00:00
|
|
|
if (strcmp(cp, first.buf))
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail1;
|
|
|
|
strbuf_release(&sp);
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&first, NULL);
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* unquoted second */
|
2016-05-24 08:11:09 +00:00
|
|
|
cp = skip_tree_prefix(state, second, line + llen - second);
|
2012-08-25 05:48:55 +00:00
|
|
|
if (!cp)
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail1;
|
2012-08-25 05:48:55 +00:00
|
|
|
if (line + llen - cp != first.len ||
|
2007-09-19 22:42:14 +00:00
|
|
|
memcmp(first.buf, cp, first.len))
|
|
|
|
goto free_and_fail1;
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&first, NULL);
|
2007-09-19 22:42:14 +00:00
|
|
|
|
|
|
|
free_and_fail1:
|
|
|
|
strbuf_release(&first);
|
|
|
|
strbuf_release(&sp);
|
|
|
|
return NULL;
|
2005-05-26 20:11:24 +00:00
|
|
|
}
|
|
|
|
|
2005-10-15 04:54:52 +00:00
|
|
|
/* unquoted first name */
|
2016-05-24 08:11:09 +00:00
|
|
|
name = skip_tree_prefix(state, line, llen);
|
2012-08-25 05:48:55 +00:00
|
|
|
if (!name)
|
2005-05-26 20:11:24 +00:00
|
|
|
return NULL;
|
2005-10-15 04:54:52 +00:00
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* since the first name is unquoted, a dq if exists must be
|
2005-10-15 04:54:52 +00:00
|
|
|
* the beginning of the second name.
|
|
|
|
*/
|
|
|
|
for (second = name; second < line + llen; second++) {
|
|
|
|
if (*second == '"') {
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf sp = STRBUF_INIT;
|
2005-10-15 04:54:52 +00:00
|
|
|
const char *np;
|
2007-09-19 22:42:14 +00:00
|
|
|
|
|
|
|
if (unquote_c_style(&sp, second, NULL))
|
|
|
|
goto free_and_fail2;
|
|
|
|
|
2016-05-24 08:11:09 +00:00
|
|
|
np = skip_tree_prefix(state, sp.buf, sp.len);
|
2012-08-25 05:48:55 +00:00
|
|
|
if (!np)
|
2007-09-19 22:42:14 +00:00
|
|
|
goto free_and_fail2;
|
|
|
|
|
|
|
|
len = sp.buf + sp.len - np;
|
|
|
|
if (len < second - name &&
|
2005-10-15 04:54:52 +00:00
|
|
|
!strncmp(np, name, len) &&
|
|
|
|
isspace(name[len])) {
|
|
|
|
/* Good */
|
2007-09-19 22:42:14 +00:00
|
|
|
strbuf_remove(&sp, 0, np - sp.buf);
|
2007-09-27 10:58:23 +00:00
|
|
|
return strbuf_detach(&sp, NULL);
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
2007-09-19 22:42:14 +00:00
|
|
|
|
|
|
|
free_and_fail2:
|
|
|
|
strbuf_release(&sp);
|
|
|
|
return NULL;
|
2005-10-15 04:54:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-26 20:11:24 +00:00
|
|
|
/*
|
|
|
|
* Accept a name only if it shows up twice, exactly the same
|
|
|
|
* form.
|
|
|
|
*/
|
2010-10-21 22:12:02 +00:00
|
|
|
second = strchr(name, '\n');
|
|
|
|
if (!second)
|
|
|
|
return NULL;
|
|
|
|
line_len = second - name;
|
2005-05-26 20:11:24 +00:00
|
|
|
for (len = 0 ; ; len++) {
|
2006-08-23 10:39:15 +00:00
|
|
|
switch (name[len]) {
|
2005-05-26 20:11:24 +00:00
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
case '\n':
|
2005-08-28 15:24:27 +00:00
|
|
|
return NULL;
|
2005-05-26 20:11:24 +00:00
|
|
|
case '\t': case ' ':
|
2012-08-25 05:48:55 +00:00
|
|
|
/*
|
|
|
|
* Is this the separator between the preimage
|
|
|
|
* and the postimage pathname? Again, we are
|
|
|
|
* only interested in the case where there is
|
|
|
|
* no rename, as this is only to set def_name
|
|
|
|
* and a rename patch has the names elsewhere
|
|
|
|
* in an unambiguous form.
|
|
|
|
*/
|
|
|
|
if (!name[len + 1])
|
|
|
|
return NULL; /* no postimage name */
|
2016-05-24 08:11:09 +00:00
|
|
|
second = skip_tree_prefix(state, name + len + 1,
|
2012-08-25 05:48:55 +00:00
|
|
|
line_len - (len + 1));
|
2010-10-21 22:12:02 +00:00
|
|
|
if (!second)
|
|
|
|
return NULL;
|
2012-08-25 05:48:55 +00:00
|
|
|
/*
|
|
|
|
* Does len bytes starting at "name" and "second"
|
|
|
|
* (that are separated by one HT or SP we just
|
|
|
|
* found) exactly match?
|
|
|
|
*/
|
|
|
|
if (second[len] == '\n' && !strncmp(name, second, len))
|
2007-09-15 22:32:36 +00:00
|
|
|
return xmemdupz(name, len);
|
2005-05-26 20:11:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-23 17:52:17 +00:00
|
|
|
/* Verify that we recognize the lines following a git header */
|
2016-05-24 08:11:09 +00:00
|
|
|
static int parse_git_header(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
int len,
|
|
|
|
unsigned int size,
|
|
|
|
struct patch *patch)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2005-05-23 23:09:09 +00:00
|
|
|
unsigned long offset;
|
|
|
|
|
|
|
|
/* A git diff has explicit new/delete information, so we don't guess */
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_new = 0;
|
|
|
|
patch->is_delete = 0;
|
2005-05-23 23:09:09 +00:00
|
|
|
|
2005-05-26 20:11:24 +00:00
|
|
|
/*
|
|
|
|
* Some things may not have the old name in the
|
|
|
|
* rest of the headers anywhere (pure mode changes,
|
|
|
|
* or removing or adding empty files), so we get
|
|
|
|
* the default name from the header.
|
|
|
|
*/
|
2016-05-24 08:11:09 +00:00
|
|
|
patch->def_name = git_header_name(state, line, len);
|
2016-05-24 08:11:11 +00:00
|
|
|
if (patch->def_name && state->root.len) {
|
|
|
|
char *s = xstrfmt("%s%s", state->root.buf, patch->def_name);
|
2008-10-12 04:06:11 +00:00
|
|
|
free(patch->def_name);
|
|
|
|
patch->def_name = s;
|
|
|
|
}
|
2005-05-26 20:11:24 +00:00
|
|
|
|
2005-05-23 23:09:09 +00:00
|
|
|
line += len;
|
|
|
|
size -= len;
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
|
|
|
for (offset = len ; size > 0 ; offset += len, size -= len, line += len, state->linenr++) {
|
2005-05-23 23:09:09 +00:00
|
|
|
static const struct opentry {
|
|
|
|
const char *str;
|
2016-05-24 08:11:09 +00:00
|
|
|
int (*fn)(struct apply_state *, const char *, struct patch *);
|
2005-05-23 23:09:09 +00:00
|
|
|
} optable[] = {
|
|
|
|
{ "@@ -", gitdiff_hdrend },
|
|
|
|
{ "--- ", gitdiff_oldname },
|
|
|
|
{ "+++ ", gitdiff_newname },
|
|
|
|
{ "old mode ", gitdiff_oldmode },
|
|
|
|
{ "new mode ", gitdiff_newmode },
|
|
|
|
{ "deleted file mode ", gitdiff_delete },
|
|
|
|
{ "new file mode ", gitdiff_newfile },
|
|
|
|
{ "copy from ", gitdiff_copysrc },
|
|
|
|
{ "copy to ", gitdiff_copydst },
|
2005-06-05 21:26:50 +00:00
|
|
|
{ "rename old ", gitdiff_renamesrc },
|
|
|
|
{ "rename new ", gitdiff_renamedst },
|
2005-06-05 22:31:52 +00:00
|
|
|
{ "rename from ", gitdiff_renamesrc },
|
|
|
|
{ "rename to ", gitdiff_renamedst },
|
2005-05-23 23:09:09 +00:00
|
|
|
{ "similarity index ", gitdiff_similarity },
|
2005-05-30 23:40:16 +00:00
|
|
|
{ "dissimilarity index ", gitdiff_dissimilarity },
|
2005-10-07 10:42:00 +00:00
|
|
|
{ "index ", gitdiff_index },
|
2005-05-24 02:13:55 +00:00
|
|
|
{ "", gitdiff_unrecognized },
|
2005-05-23 23:09:09 +00:00
|
|
|
};
|
|
|
|
int i;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
|
|
|
len = linelen(line, size);
|
2005-05-23 23:09:09 +00:00
|
|
|
if (!len || line[len-1] != '\n')
|
2005-05-23 17:52:17 +00:00
|
|
|
break;
|
2006-03-09 19:58:05 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(optable); i++) {
|
2005-05-23 23:09:09 +00:00
|
|
|
const struct opentry *p = optable + i;
|
|
|
|
int oplen = strlen(p->str);
|
2016-08-08 21:03:13 +00:00
|
|
|
int res;
|
2005-05-23 23:09:09 +00:00
|
|
|
if (len < oplen || memcmp(p->str, line, oplen))
|
|
|
|
continue;
|
2016-08-08 21:03:13 +00:00
|
|
|
res = p->fn(state, line + oplen, patch);
|
|
|
|
if (res < 0)
|
|
|
|
return -1;
|
|
|
|
if (res > 0)
|
2005-05-23 23:09:09 +00:00
|
|
|
return offset;
|
2005-05-24 02:13:55 +00:00
|
|
|
break;
|
2005-05-23 23:09:09 +00:00
|
|
|
}
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
|
2005-05-23 23:09:09 +00:00
|
|
|
return offset;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
|
2005-05-26 19:25:52 +00:00
|
|
|
static int parse_num(const char *line, unsigned long *p)
|
2005-05-23 21:38:49 +00:00
|
|
|
{
|
|
|
|
char *ptr;
|
2005-05-26 19:25:52 +00:00
|
|
|
|
|
|
|
if (!isdigit(*line))
|
|
|
|
return 0;
|
|
|
|
*p = strtoul(line, &ptr, 10);
|
|
|
|
return ptr - line;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_range(const char *line, int len, int offset, const char *expect,
|
2007-11-23 10:37:03 +00:00
|
|
|
unsigned long *p1, unsigned long *p2)
|
2005-05-26 19:25:52 +00:00
|
|
|
{
|
2005-05-23 21:38:49 +00:00
|
|
|
int digits, ex;
|
|
|
|
|
|
|
|
if (offset < 0 || offset >= len)
|
|
|
|
return -1;
|
|
|
|
line += offset;
|
|
|
|
len -= offset;
|
|
|
|
|
2005-05-26 19:25:52 +00:00
|
|
|
digits = parse_num(line, p1);
|
|
|
|
if (!digits)
|
2005-05-23 21:38:49 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
offset += digits;
|
|
|
|
line += digits;
|
|
|
|
len -= digits;
|
|
|
|
|
2006-03-25 21:28:28 +00:00
|
|
|
*p2 = 1;
|
2005-05-26 19:25:52 +00:00
|
|
|
if (*line == ',') {
|
|
|
|
digits = parse_num(line+1, p2);
|
|
|
|
if (!digits)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
offset += digits+1;
|
|
|
|
line += digits+1;
|
|
|
|
len -= digits+1;
|
|
|
|
}
|
|
|
|
|
2005-05-23 21:38:49 +00:00
|
|
|
ex = strlen(expect);
|
|
|
|
if (ex > len)
|
|
|
|
return -1;
|
|
|
|
if (memcmp(line, expect, ex))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return offset + ex;
|
|
|
|
}
|
|
|
|
|
2012-04-11 21:41:42 +00:00
|
|
|
static void recount_diff(const char *line, int size, struct fragment *fragment)
|
2008-06-27 17:43:09 +00:00
|
|
|
{
|
|
|
|
int oldlines = 0, newlines = 0, ret = 0;
|
|
|
|
|
|
|
|
if (size < 1) {
|
|
|
|
warning("recount: ignore empty hunk");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
int len = linelen(line, size);
|
|
|
|
size -= len;
|
|
|
|
line += len;
|
|
|
|
|
|
|
|
if (size < 1)
|
|
|
|
break;
|
|
|
|
|
|
|
|
switch (*line) {
|
|
|
|
case ' ': case '\n':
|
|
|
|
newlines++;
|
|
|
|
/* fall through */
|
|
|
|
case '-':
|
|
|
|
oldlines++;
|
|
|
|
continue;
|
|
|
|
case '+':
|
|
|
|
newlines++;
|
|
|
|
continue;
|
|
|
|
case '\\':
|
2008-07-04 19:10:14 +00:00
|
|
|
continue;
|
2008-06-27 17:43:09 +00:00
|
|
|
case '@':
|
2013-11-30 20:55:40 +00:00
|
|
|
ret = size < 3 || !starts_with(line, "@@ ");
|
2008-06-27 17:43:09 +00:00
|
|
|
break;
|
|
|
|
case 'd':
|
2013-11-30 20:55:40 +00:00
|
|
|
ret = size < 5 || !starts_with(line, "diff ");
|
2008-06-27 17:43:09 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ret) {
|
2012-04-23 12:30:27 +00:00
|
|
|
warning(_("recount: unexpected line: %.*s"),
|
2008-06-27 17:43:09 +00:00
|
|
|
(int)linelen(line, size), line);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
fragment->oldlines = oldlines;
|
|
|
|
fragment->newlines = newlines;
|
|
|
|
}
|
|
|
|
|
2005-05-23 21:38:49 +00:00
|
|
|
/*
|
|
|
|
* Parse a unified diff fragment header of the
|
|
|
|
* form "@@ -a,b +c,d @@"
|
|
|
|
*/
|
2012-04-11 21:41:42 +00:00
|
|
|
static int parse_fragment_header(const char *line, int len, struct fragment *fragment)
|
2005-05-23 21:38:49 +00:00
|
|
|
{
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
if (!len || line[len-1] != '\n')
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/* Figure out the number of lines in a fragment */
|
2005-05-26 19:25:52 +00:00
|
|
|
offset = parse_range(line, len, 4, " +", &fragment->oldpos, &fragment->oldlines);
|
|
|
|
offset = parse_range(line, len, offset, " @@", &fragment->newpos, &fragment->newlines);
|
2005-05-23 21:38:49 +00:00
|
|
|
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:02 +00:00
|
|
|
/*
|
|
|
|
* Find file diff header
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* -1 if no header was found
|
|
|
|
* -128 in case of error
|
|
|
|
* the size of the header in bytes (called "offset") otherwise
|
|
|
|
*/
|
2016-05-11 13:16:19 +00:00
|
|
|
static int find_header(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
unsigned long size,
|
|
|
|
int *hdrsize,
|
|
|
|
struct patch *patch)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
|
|
|
unsigned long offset, len;
|
|
|
|
|
2007-02-21 22:31:10 +00:00
|
|
|
patch->is_toplevel_relative = 0;
|
2005-05-26 17:23:51 +00:00
|
|
|
patch->is_rename = patch->is_copy = 0;
|
|
|
|
patch->is_new = patch->is_delete = -1;
|
|
|
|
patch->old_mode = patch->new_mode = 0;
|
|
|
|
patch->old_name = patch->new_name = NULL;
|
2016-05-24 08:11:20 +00:00
|
|
|
for (offset = 0; size > 0; offset += len, size -= len, line += len, state->linenr++) {
|
2005-05-23 17:52:17 +00:00
|
|
|
unsigned long nextlen;
|
|
|
|
|
|
|
|
len = linelen(line, size);
|
|
|
|
if (!len)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Testing this early allows us to take a few shortcuts.. */
|
|
|
|
if (len < 6)
|
|
|
|
continue;
|
2005-05-23 21:38:49 +00:00
|
|
|
|
|
|
|
/*
|
2006-07-10 05:50:18 +00:00
|
|
|
* Make sure we don't find any unconnected patch fragments.
|
2005-05-23 21:38:49 +00:00
|
|
|
* That's a sign that we didn't find a header, and that a
|
|
|
|
* patch has become corrupted/broken up.
|
|
|
|
*/
|
|
|
|
if (!memcmp("@@ -", line, 4)) {
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment dummy;
|
|
|
|
if (parse_fragment_header(line, len, &dummy) < 0)
|
2005-05-23 21:38:49 +00:00
|
|
|
continue;
|
2016-08-08 21:03:02 +00:00
|
|
|
error(_("patch fragment without header at line %d: %.*s"),
|
|
|
|
state->linenr, (int)len-1, line);
|
|
|
|
return -128;
|
2005-05-23 21:38:49 +00:00
|
|
|
}
|
|
|
|
|
2005-05-23 17:52:17 +00:00
|
|
|
if (size < len + 6)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Git patch? It might not have a real patch, just a rename
|
|
|
|
* or mode change, so we handle that specially
|
|
|
|
*/
|
|
|
|
if (!memcmp("diff --git ", line, 11)) {
|
2016-05-24 08:11:09 +00:00
|
|
|
int git_hdr_len = parse_git_header(state, line, len, size, patch);
|
2016-08-08 21:03:13 +00:00
|
|
|
if (git_hdr_len < 0)
|
|
|
|
return -128;
|
2005-06-12 16:37:49 +00:00
|
|
|
if (git_hdr_len <= len)
|
2005-05-23 17:52:17 +00:00
|
|
|
continue;
|
2005-06-17 22:23:40 +00:00
|
|
|
if (!patch->old_name && !patch->new_name) {
|
2016-08-08 21:03:02 +00:00
|
|
|
if (!patch->def_name) {
|
|
|
|
error(Q_("git diff header lacks filename information when removing "
|
|
|
|
"%d leading pathname component (line %d)",
|
|
|
|
"git diff header lacks filename information when removing "
|
|
|
|
"%d leading pathname components (line %d)",
|
|
|
|
state->p_value),
|
|
|
|
state->p_value, state->linenr);
|
|
|
|
return -128;
|
|
|
|
}
|
2012-03-21 22:18:18 +00:00
|
|
|
patch->old_name = xstrdup(patch->def_name);
|
|
|
|
patch->new_name = xstrdup(patch->def_name);
|
2005-06-17 22:23:40 +00:00
|
|
|
}
|
2016-08-08 21:03:02 +00:00
|
|
|
if (!patch->is_delete && !patch->new_name) {
|
|
|
|
error("git diff header lacks filename information "
|
|
|
|
"(line %d)", state->linenr);
|
|
|
|
return -128;
|
|
|
|
}
|
2007-02-21 22:31:10 +00:00
|
|
|
patch->is_toplevel_relative = 1;
|
2005-05-23 23:09:09 +00:00
|
|
|
*hdrsize = git_hdr_len;
|
2005-05-23 17:52:17 +00:00
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/* --- followed by +++ ? */
|
2005-05-23 17:52:17 +00:00
|
|
|
if (memcmp("--- ", line, 4) || memcmp("+++ ", line + len, 4))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We only accept unified patches, so we want it to
|
|
|
|
* at least have "@@ -a,b +c,d @@\n", which is 14 chars
|
2007-11-23 10:37:03 +00:00
|
|
|
* minimum ("@@ -0,0 +1 @@\n" is the shortest).
|
2005-05-23 17:52:17 +00:00
|
|
|
*/
|
|
|
|
nextlen = linelen(line + len, size - len);
|
|
|
|
if (size < nextlen + 14 || memcmp("@@ -", line + len + nextlen, 4))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Ok, we'll consider it a patch */
|
2016-08-08 21:03:12 +00:00
|
|
|
if (parse_traditional_patch(state, line, line+len, patch))
|
|
|
|
return -128;
|
2005-05-23 17:52:17 +00:00
|
|
|
*hdrsize = len + nextlen;
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr += 2;
|
2005-05-23 17:52:17 +00:00
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:06 +00:00
|
|
|
static void record_ws_error(struct apply_state *state,
|
|
|
|
unsigned result,
|
|
|
|
const char *line,
|
|
|
|
int len,
|
|
|
|
int linenr)
|
2006-09-23 07:37:19 +00:00
|
|
|
{
|
2007-12-13 13:32:29 +00:00
|
|
|
char *err;
|
2009-09-04 05:26:33 +00:00
|
|
|
|
2007-12-13 13:32:29 +00:00
|
|
|
if (!result)
|
|
|
|
return;
|
2006-09-23 07:37:19 +00:00
|
|
|
|
2016-05-24 08:11:12 +00:00
|
|
|
state->whitespace_error++;
|
2016-05-24 08:11:15 +00:00
|
|
|
if (state->squelch_whitespace_errors &&
|
|
|
|
state->squelch_whitespace_errors < state->whitespace_error)
|
2009-09-04 05:26:33 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
err = whitespace_error_string(result);
|
|
|
|
fprintf(stderr, "%s:%d: %s.\n%.*s\n",
|
2016-05-24 08:11:06 +00:00
|
|
|
state->patch_input_file, linenr, err, len, line);
|
2009-09-04 05:26:33 +00:00
|
|
|
free(err);
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:06 +00:00
|
|
|
static void check_whitespace(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
int len,
|
|
|
|
unsigned ws_rule)
|
2009-09-04 05:26:33 +00:00
|
|
|
{
|
|
|
|
unsigned result = ws_check(line + 1, len - 1, ws_rule);
|
|
|
|
|
2016-05-24 08:11:20 +00:00
|
|
|
record_ws_error(state, result, line + 1, len - 2, state->linenr);
|
2006-09-23 07:37:19 +00:00
|
|
|
}
|
|
|
|
|
2005-05-23 17:52:17 +00:00
|
|
|
/*
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
* Parse a unified diff. Note that this really needs to parse each
|
|
|
|
* fragment separately, since the only way to know the difference
|
|
|
|
* between a "---" that is part of a patch, and a "---" that starts
|
|
|
|
* the next patch is to look at the line counts..
|
2005-05-23 17:52:17 +00:00
|
|
|
*/
|
2016-05-24 08:10:50 +00:00
|
|
|
static int parse_fragment(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
unsigned long size,
|
|
|
|
struct patch *patch,
|
|
|
|
struct fragment *fragment)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2005-05-26 18:40:43 +00:00
|
|
|
int added, deleted;
|
2005-05-23 17:52:17 +00:00
|
|
|
int len = linelen(line, size), offset;
|
2005-06-05 19:43:56 +00:00
|
|
|
unsigned long oldlines, newlines;
|
2006-04-10 09:33:06 +00:00
|
|
|
unsigned long leading, trailing;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2005-05-26 17:23:51 +00:00
|
|
|
offset = parse_fragment_header(line, len, fragment);
|
2005-05-23 17:52:17 +00:00
|
|
|
if (offset < 0)
|
|
|
|
return -1;
|
2008-06-27 17:43:09 +00:00
|
|
|
if (offset > 0 && patch->recount)
|
|
|
|
recount_diff(line + offset, size - offset, fragment);
|
2005-05-26 17:23:51 +00:00
|
|
|
oldlines = fragment->oldlines;
|
|
|
|
newlines = fragment->newlines;
|
2006-04-10 09:33:06 +00:00
|
|
|
leading = 0;
|
|
|
|
trailing = 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
|
|
|
/* Parse the thing.. */
|
|
|
|
line += len;
|
|
|
|
size -= len;
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
2005-05-26 18:40:43 +00:00
|
|
|
added = deleted = 0;
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
for (offset = len;
|
|
|
|
0 < size;
|
2016-05-24 08:11:20 +00:00
|
|
|
offset += len, size -= len, line += len, state->linenr++) {
|
2005-05-23 17:52:17 +00:00
|
|
|
if (!oldlines && !newlines)
|
|
|
|
break;
|
|
|
|
len = linelen(line, size);
|
|
|
|
if (!len || line[len-1] != '\n')
|
|
|
|
return -1;
|
|
|
|
switch (*line) {
|
|
|
|
default:
|
|
|
|
return -1;
|
2006-10-20 02:26:08 +00:00
|
|
|
case '\n': /* newer GNU diff, an empty context line */
|
2005-05-23 17:52:17 +00:00
|
|
|
case ' ':
|
|
|
|
oldlines--;
|
|
|
|
newlines--;
|
2006-04-10 09:33:06 +00:00
|
|
|
if (!deleted && !added)
|
|
|
|
leading++;
|
|
|
|
trailing++;
|
2016-05-24 08:10:50 +00:00
|
|
|
if (!state->apply_in_reverse &&
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action == correct_ws_error)
|
2016-05-24 08:11:06 +00:00
|
|
|
check_whitespace(state, line, len, patch->ws_rule);
|
2005-05-23 17:52:17 +00:00
|
|
|
break;
|
|
|
|
case '-':
|
2016-05-24 08:10:50 +00:00
|
|
|
if (state->apply_in_reverse &&
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action != nowarn_ws_error)
|
2016-05-24 08:11:06 +00:00
|
|
|
check_whitespace(state, line, len, patch->ws_rule);
|
2005-05-26 18:40:43 +00:00
|
|
|
deleted++;
|
2005-05-23 17:52:17 +00:00
|
|
|
oldlines--;
|
2006-04-10 09:33:06 +00:00
|
|
|
trailing = 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
break;
|
|
|
|
case '+':
|
2016-05-24 08:10:50 +00:00
|
|
|
if (!state->apply_in_reverse &&
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action != nowarn_ws_error)
|
2016-05-24 08:11:06 +00:00
|
|
|
check_whitespace(state, line, len, patch->ws_rule);
|
2005-05-26 18:40:43 +00:00
|
|
|
added++;
|
2005-05-23 17:52:17 +00:00
|
|
|
newlines--;
|
2006-04-10 09:33:06 +00:00
|
|
|
trailing = 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
break;
|
2005-09-04 17:29:02 +00:00
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* We allow "\ No newline at end of file". Depending
|
2005-09-04 17:29:02 +00:00
|
|
|
* on locale settings when the patch was produced we
|
|
|
|
* don't know what this line looks like. The only
|
2005-10-03 20:16:39 +00:00
|
|
|
* thing we do know is that it begins with "\ ".
|
|
|
|
* Checking for 12 is just for sanity check -- any
|
|
|
|
* l10n of "\ No newline..." is at least that long.
|
|
|
|
*/
|
2005-05-26 19:25:52 +00:00
|
|
|
case '\\':
|
2005-09-04 17:29:02 +00:00
|
|
|
if (len < 12 || memcmp(line, "\\ ", 2))
|
2005-06-05 18:03:13 +00:00
|
|
|
return -1;
|
2005-05-26 19:25:52 +00:00
|
|
|
break;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
}
|
2006-03-25 21:28:28 +00:00
|
|
|
if (oldlines || newlines)
|
|
|
|
return -1;
|
2015-06-01 19:12:04 +00:00
|
|
|
if (!deleted && !added)
|
|
|
|
return -1;
|
|
|
|
|
2006-04-10 09:33:06 +00:00
|
|
|
fragment->leading = leading;
|
|
|
|
fragment->trailing = trailing;
|
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* If a fragment ends with an incomplete line, we failed to include
|
2005-07-22 16:56:39 +00:00
|
|
|
* it in the above loop because we hit oldlines == newlines == 0
|
|
|
|
* before seeing it.
|
|
|
|
*/
|
2005-09-04 17:29:02 +00:00
|
|
|
if (12 < size && !memcmp(line, "\\ ", 2))
|
2005-07-22 16:56:39 +00:00
|
|
|
offset += linelen(line, size);
|
|
|
|
|
2005-05-26 18:40:43 +00:00
|
|
|
patch->lines_added += added;
|
|
|
|
patch->lines_deleted += deleted;
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
|
|
|
|
if (0 < patch->is_new && oldlines)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("new file depends on old contents"));
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (0 < patch->is_delete && newlines)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("deleted file still has contents"));
|
2005-05-23 17:52:17 +00:00
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* We have seen "diff --git a/... b/..." header (or a traditional patch
|
|
|
|
* header). Read hunks that belong to this patch into fragments and hang
|
|
|
|
* them to the given patch structure.
|
|
|
|
*
|
|
|
|
* The (fragment->patch, fragment->size) pair points into the memory given
|
|
|
|
* by the caller, not a copy, when we return.
|
2016-08-08 21:03:04 +00:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* -1 in case of error,
|
|
|
|
* the number of bytes in the patch otherwise.
|
2012-04-11 21:43:48 +00:00
|
|
|
*/
|
2016-05-24 08:10:50 +00:00
|
|
|
static int parse_single_patch(struct apply_state *state,
|
|
|
|
const char *line,
|
|
|
|
unsigned long size,
|
|
|
|
struct patch *patch)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
|
|
|
unsigned long offset = 0;
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
unsigned long oldlines = 0, newlines = 0, context = 0;
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment **fragp = &patch->fragments;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
|
|
|
while (size > 4 && !memcmp(line, "@@ -", 4)) {
|
2005-05-26 17:23:51 +00:00
|
|
|
struct fragment *fragment;
|
|
|
|
int len;
|
|
|
|
|
2006-04-03 18:30:46 +00:00
|
|
|
fragment = xcalloc(1, sizeof(*fragment));
|
2016-05-24 08:11:20 +00:00
|
|
|
fragment->linenr = state->linenr;
|
2016-05-24 08:10:50 +00:00
|
|
|
len = parse_fragment(state, line, size, patch, fragment);
|
2016-08-08 21:03:04 +00:00
|
|
|
if (len <= 0) {
|
|
|
|
free(fragment);
|
|
|
|
return error(_("corrupt patch at line %d"), state->linenr);
|
|
|
|
}
|
2005-05-26 17:23:51 +00:00
|
|
|
fragment->patch = line;
|
|
|
|
fragment->size = len;
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
oldlines += fragment->oldlines;
|
|
|
|
newlines += fragment->newlines;
|
|
|
|
context += fragment->leading + fragment->trailing;
|
2005-05-26 17:23:51 +00:00
|
|
|
|
|
|
|
*fragp = fragment;
|
|
|
|
fragp = &fragment->next;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
|
|
|
offset += len;
|
|
|
|
line += len;
|
|
|
|
size -= len;
|
|
|
|
}
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If something was removed (i.e. we have old-lines) it cannot
|
|
|
|
* be creation, and if something was added it cannot be
|
|
|
|
* deletion. However, the reverse is not true; --unified=0
|
|
|
|
* patches that only add are not necessarily creation even
|
|
|
|
* though they do not have any old lines, and ones that only
|
|
|
|
* delete are not necessarily deletion.
|
|
|
|
*
|
|
|
|
* Unfortunately, a real creation/deletion patch do _not_ have
|
|
|
|
* any context line by definition, so we cannot safely tell it
|
|
|
|
* apart with --unified=0 insanity. At least if the patch has
|
|
|
|
* more than one hunk it is not creation or deletion.
|
|
|
|
*/
|
|
|
|
if (patch->is_new < 0 &&
|
|
|
|
(oldlines || (patch->fragments && patch->fragments->next)))
|
|
|
|
patch->is_new = 0;
|
|
|
|
if (patch->is_delete < 0 &&
|
|
|
|
(newlines || (patch->fragments && patch->fragments->next)))
|
|
|
|
patch->is_delete = 0;
|
|
|
|
|
|
|
|
if (0 < patch->is_new && oldlines)
|
2016-08-08 21:03:04 +00:00
|
|
|
return error(_("new file %s depends on old contents"), patch->new_name);
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (0 < patch->is_delete && newlines)
|
2016-08-08 21:03:04 +00:00
|
|
|
return error(_("deleted file %s still has contents"), patch->old_name);
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (!patch->is_delete && !newlines && context)
|
2012-04-23 12:30:27 +00:00
|
|
|
fprintf_ln(stderr,
|
|
|
|
_("** warning: "
|
|
|
|
"file %s becomes empty but is not deleted"),
|
|
|
|
patch->new_name);
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
|
2005-05-23 17:52:17 +00:00
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
2005-10-01 06:25:23 +00:00
|
|
|
static inline int metadata_changes(struct patch *patch)
|
|
|
|
{
|
|
|
|
return patch->is_rename > 0 ||
|
|
|
|
patch->is_copy > 0 ||
|
|
|
|
patch->is_new > 0 ||
|
|
|
|
patch->is_delete ||
|
|
|
|
(patch->old_mode && patch->new_mode &&
|
|
|
|
patch->old_mode != patch->new_mode);
|
|
|
|
}
|
|
|
|
|
2006-08-15 09:23:06 +00:00
|
|
|
static char *inflate_it(const void *data, unsigned long size,
|
|
|
|
unsigned long inflated_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
|
|
|
{
|
2011-06-10 18:52:15 +00:00
|
|
|
git_zstream stream;
|
2006-08-15 09:23:06 +00:00
|
|
|
void *out;
|
|
|
|
int st;
|
|
|
|
|
|
|
|
memset(&stream, 0, sizeof(stream));
|
|
|
|
|
|
|
|
stream.next_in = (unsigned char *)data;
|
|
|
|
stream.avail_in = size;
|
|
|
|
stream.next_out = out = xmalloc(inflated_size);
|
|
|
|
stream.avail_out = inflated_size;
|
2009-01-08 03:54:47 +00:00
|
|
|
git_inflate_init(&stream);
|
|
|
|
st = git_inflate(&stream, Z_FINISH);
|
|
|
|
git_inflate_end(&stream);
|
2006-08-15 09:23:06 +00:00
|
|
|
if ((st != Z_STREAM_END) || stream.total_out != inflated_size) {
|
|
|
|
free(out);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return out;
|
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* Read a binary hunk and return a new fragment; fragment->patch
|
|
|
|
* points at an allocated memory that the caller must free, so
|
|
|
|
* it is marked as "->free_patch = 1".
|
|
|
|
*/
|
2016-05-24 08:11:20 +00:00
|
|
|
static struct fragment *parse_binary_hunk(struct apply_state *state,
|
|
|
|
char **buf_p,
|
2006-08-15 09:23:06 +00:00
|
|
|
unsigned long *sz_p,
|
|
|
|
int *status_p,
|
|
|
|
int *used_p)
|
|
|
|
{
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* Expect a line that begins with binary patch method ("literal"
|
2006-08-15 09:23:06 +00:00
|
|
|
* or "delta"), followed by the length of data before deflating.
|
|
|
|
* a sequence of 'length-byte' followed by base-85 encoded data
|
|
|
|
* should follow, terminated by a newline.
|
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
|
|
|
*
|
|
|
|
* Each 5-byte sequence of base-85 encodes up to 4 bytes,
|
|
|
|
* and we would limit the patch line to 66 characters,
|
|
|
|
* so one line can fit up to 13 groups that would decode
|
|
|
|
* to 52 bytes max. The length byte 'A'-'Z' corresponds
|
|
|
|
* to 1-26 bytes, and 'a'-'z' corresponds to 27-52 bytes.
|
|
|
|
*/
|
|
|
|
int llen, used;
|
2006-08-15 09:23:06 +00:00
|
|
|
unsigned long size = *sz_p;
|
|
|
|
char *buffer = *buf_p;
|
|
|
|
int patch_method;
|
|
|
|
unsigned long origlen;
|
2006-05-05 09:41:53 +00:00
|
|
|
char *data = NULL;
|
2006-08-15 09:23:06 +00:00
|
|
|
int hunk_size = 0;
|
|
|
|
struct fragment *frag;
|
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
|
|
|
llen = linelen(buffer, size);
|
|
|
|
used = llen;
|
2006-08-15 09:23:06 +00:00
|
|
|
|
|
|
|
*status_p = 0;
|
2006-05-05 09:41:53 +00:00
|
|
|
|
2013-11-30 20:55:40 +00:00
|
|
|
if (starts_with(buffer, "delta ")) {
|
2006-08-15 09:23:06 +00:00
|
|
|
patch_method = BINARY_DELTA_DEFLATED;
|
|
|
|
origlen = strtoul(buffer + 6, NULL, 10);
|
2006-05-05 09:41:53 +00:00
|
|
|
}
|
2013-11-30 20:55:40 +00:00
|
|
|
else if (starts_with(buffer, "literal ")) {
|
2006-08-15 09:23:06 +00:00
|
|
|
patch_method = BINARY_LITERAL_DEFLATED;
|
|
|
|
origlen = strtoul(buffer + 8, NULL, 10);
|
2006-05-05 09:41:53 +00:00
|
|
|
}
|
|
|
|
else
|
2006-08-15 09:23:06 +00:00
|
|
|
return NULL;
|
|
|
|
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
2006-05-05 09:41:53 +00:00
|
|
|
buffer += llen;
|
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
|
|
|
while (1) {
|
|
|
|
int byte_length, max_byte_length, newsize;
|
|
|
|
llen = linelen(buffer, size);
|
|
|
|
used += llen;
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
2006-08-16 23:07:20 +00:00
|
|
|
if (llen == 1) {
|
|
|
|
/* consume the blank line */
|
|
|
|
buffer++;
|
|
|
|
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
|
|
|
break;
|
2006-08-16 23:07:20 +00:00
|
|
|
}
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* Minimum line is "A00000\n" which is 7-byte long,
|
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
|
|
|
* and the line length must be multiple of 5 plus 2.
|
|
|
|
*/
|
|
|
|
if ((llen < 7) || (llen-2) % 5)
|
|
|
|
goto corrupt;
|
|
|
|
max_byte_length = (llen - 2) / 5 * 4;
|
|
|
|
byte_length = *buffer;
|
|
|
|
if ('A' <= byte_length && byte_length <= 'Z')
|
|
|
|
byte_length = byte_length - 'A' + 1;
|
|
|
|
else if ('a' <= byte_length && byte_length <= 'z')
|
|
|
|
byte_length = byte_length - 'a' + 27;
|
|
|
|
else
|
|
|
|
goto corrupt;
|
|
|
|
/* if the input length was not multiple of 4, we would
|
|
|
|
* have filler at the end but the filler should never
|
|
|
|
* exceed 3 bytes
|
|
|
|
*/
|
|
|
|
if (max_byte_length < byte_length ||
|
|
|
|
byte_length <= max_byte_length - 4)
|
|
|
|
goto corrupt;
|
2006-08-15 09:23:06 +00:00
|
|
|
newsize = hunk_size + byte_length;
|
2006-05-05 09:41:53 +00:00
|
|
|
data = xrealloc(data, newsize);
|
2006-08-15 09:23:06 +00:00
|
|
|
if (decode_85(data + hunk_size, buffer + 1, byte_length))
|
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
|
|
|
goto corrupt;
|
2006-08-15 09:23:06 +00:00
|
|
|
hunk_size = newsize;
|
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
|
|
|
buffer += llen;
|
|
|
|
size -= llen;
|
|
|
|
}
|
2006-08-15 09:23:06 +00:00
|
|
|
|
|
|
|
frag = xcalloc(1, sizeof(*frag));
|
|
|
|
frag->patch = inflate_it(data, hunk_size, origlen);
|
2012-03-07 22:21:25 +00:00
|
|
|
frag->free_patch = 1;
|
2006-08-15 09:23:06 +00:00
|
|
|
if (!frag->patch)
|
|
|
|
goto corrupt;
|
|
|
|
free(data);
|
|
|
|
frag->size = origlen;
|
|
|
|
*buf_p = buffer;
|
|
|
|
*sz_p = size;
|
|
|
|
*used_p = used;
|
|
|
|
frag->binary_patch_method = patch_method;
|
|
|
|
return frag;
|
|
|
|
|
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
|
|
|
corrupt:
|
2006-08-28 04:19:39 +00:00
|
|
|
free(data);
|
2006-08-15 09:23:06 +00:00
|
|
|
*status_p = -1;
|
2012-04-23 12:30:27 +00:00
|
|
|
error(_("corrupt binary patch at line %d: %.*s"),
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr-1, llen-1, buffer);
|
2006-08-15 09:23:06 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-03-18 12:30:41 +00:00
|
|
|
/*
|
|
|
|
* Returns:
|
|
|
|
* -1 in case of error,
|
|
|
|
* the length of the parsed binary patch otherwise
|
|
|
|
*/
|
2016-05-24 08:11:20 +00:00
|
|
|
static int parse_binary(struct apply_state *state,
|
|
|
|
char *buffer,
|
|
|
|
unsigned long size,
|
|
|
|
struct patch *patch)
|
2006-08-15 09:23:06 +00:00
|
|
|
{
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* We have read "GIT binary patch\n"; what follows is a line
|
2006-08-15 09:23:06 +00:00
|
|
|
* that says the patch method (currently, either "literal" or
|
|
|
|
* "delta") and the length of data before deflating; a
|
|
|
|
* sequence of 'length-byte' followed by base-85 encoded data
|
|
|
|
* follows.
|
|
|
|
*
|
|
|
|
* When a binary patch is reversible, there is another binary
|
|
|
|
* hunk in the same format, starting with patch method (either
|
|
|
|
* "literal" or "delta") with the length of data, and a sequence
|
|
|
|
* of length-byte + base-85 encoded data, terminated with another
|
|
|
|
* empty line. This data, when applied to the postimage, produces
|
|
|
|
* the preimage.
|
|
|
|
*/
|
|
|
|
struct fragment *forward;
|
|
|
|
struct fragment *reverse;
|
|
|
|
int status;
|
|
|
|
int used, used_1;
|
|
|
|
|
2016-05-24 08:11:20 +00:00
|
|
|
forward = parse_binary_hunk(state, &buffer, &size, &status, &used);
|
2006-08-15 09:23:06 +00:00
|
|
|
if (!forward && !status)
|
|
|
|
/* there has to be one hunk (forward hunk) */
|
2016-05-24 08:11:20 +00:00
|
|
|
return error(_("unrecognized binary patch at line %d"), state->linenr-1);
|
2006-08-15 09:23:06 +00:00
|
|
|
if (status)
|
|
|
|
/* otherwise we already gave an error message */
|
|
|
|
return status;
|
|
|
|
|
2016-05-24 08:11:20 +00:00
|
|
|
reverse = parse_binary_hunk(state, &buffer, &size, &status, &used_1);
|
2006-08-15 09:23:06 +00:00
|
|
|
if (reverse)
|
|
|
|
used += used_1;
|
|
|
|
else if (status) {
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* Not having reverse hunk is not an error, but having
|
2006-08-15 09:23:06 +00:00
|
|
|
* a corrupt reverse hunk is.
|
|
|
|
*/
|
|
|
|
free((void*) forward->patch);
|
|
|
|
free(forward);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
forward->next = reverse;
|
|
|
|
patch->fragments = forward;
|
|
|
|
patch->is_binary = 1;
|
|
|
|
return used;
|
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
|
|
|
}
|
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
static void prefix_one(struct apply_state *state, char **name)
|
2014-08-06 21:26:24 +00:00
|
|
|
{
|
|
|
|
char *old_name = *name;
|
|
|
|
if (!old_name)
|
|
|
|
return;
|
2016-05-11 13:16:19 +00:00
|
|
|
*name = xstrdup(prefix_filename(state->prefix, state->prefix_length, *name));
|
2014-08-06 21:26:24 +00:00
|
|
|
free(old_name);
|
|
|
|
}
|
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
static void prefix_patch(struct apply_state *state, struct patch *p)
|
2014-08-06 21:26:24 +00:00
|
|
|
{
|
2016-05-11 13:16:19 +00:00
|
|
|
if (!state->prefix || p->is_toplevel_relative)
|
2014-08-06 21:26:24 +00:00
|
|
|
return;
|
2016-05-11 13:16:19 +00:00
|
|
|
prefix_one(state, &p->new_name);
|
|
|
|
prefix_one(state, &p->old_name);
|
2014-08-06 21:26:24 +00:00
|
|
|
}
|
|
|
|
|
2014-08-06 20:11:17 +00:00
|
|
|
/*
|
|
|
|
* include/exclude
|
|
|
|
*/
|
|
|
|
|
2016-05-24 08:11:07 +00:00
|
|
|
static void add_name_limit(struct apply_state *state,
|
|
|
|
const char *name,
|
|
|
|
int exclude)
|
2014-08-06 20:11:17 +00:00
|
|
|
{
|
|
|
|
struct string_list_item *it;
|
|
|
|
|
2016-05-24 08:11:07 +00:00
|
|
|
it = string_list_append(&state->limit_by_name, name);
|
2014-08-06 20:11:17 +00:00
|
|
|
it->util = exclude ? NULL : (void *) 1;
|
|
|
|
}
|
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
static int use_patch(struct apply_state *state, struct patch *p)
|
2014-08-06 20:11:17 +00:00
|
|
|
{
|
|
|
|
const char *pathname = p->new_name ? p->new_name : p->old_name;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Paths outside are not touched regardless of "--include" */
|
2016-05-11 13:16:19 +00:00
|
|
|
if (0 < state->prefix_length) {
|
2014-08-06 20:11:17 +00:00
|
|
|
int pathlen = strlen(pathname);
|
2016-05-11 13:16:19 +00:00
|
|
|
if (pathlen <= state->prefix_length ||
|
|
|
|
memcmp(state->prefix, pathname, state->prefix_length))
|
2014-08-06 20:11:17 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See if it matches any of exclude/include rule */
|
2016-05-24 08:11:07 +00:00
|
|
|
for (i = 0; i < state->limit_by_name.nr; i++) {
|
|
|
|
struct string_list_item *it = &state->limit_by_name.items[i];
|
2014-09-09 19:53:58 +00:00
|
|
|
if (!wildmatch(it->string, pathname, 0, NULL))
|
2014-08-06 20:11:17 +00:00
|
|
|
return (it->util != NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we had any include, a path that does not match any rule is
|
|
|
|
* not used. Otherwise, we saw bunch of exclude rules (or none)
|
|
|
|
* and such a path is used.
|
|
|
|
*/
|
2016-05-24 08:11:08 +00:00
|
|
|
return !state->has_include;
|
2014-08-06 20:11:17 +00:00
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
2013-04-11 22:36:10 +00:00
|
|
|
* Read the patch text in "buffer" that extends for "size" bytes; stop
|
2012-04-11 21:43:48 +00:00
|
|
|
* reading after seeing a single patch (i.e. changes to a single file).
|
|
|
|
* Create fragments (i.e. patch hunks) and hang them to the given patch.
|
2016-08-08 21:03:03 +00:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* -1 if no header was found or parse_binary() failed,
|
|
|
|
* -128 on another error,
|
|
|
|
* the number of bytes consumed otherwise,
|
|
|
|
* so that the caller can call us again for the next patch.
|
2012-04-11 21:43:48 +00:00
|
|
|
*/
|
2016-05-11 13:16:19 +00:00
|
|
|
static int parse_chunk(struct apply_state *state, char *buffer, unsigned long size, struct patch *patch)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
|
|
|
int hdrsize, patchsize;
|
2016-05-11 13:16:19 +00:00
|
|
|
int offset = find_header(state, buffer, size, &hdrsize, patch);
|
2005-05-23 17:52:17 +00:00
|
|
|
|
|
|
|
if (offset < 0)
|
|
|
|
return offset;
|
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
prefix_patch(state, patch);
|
2014-08-06 21:26:24 +00:00
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
if (!use_patch(state, patch))
|
2014-08-06 20:09:05 +00:00
|
|
|
patch->ws_rule = 0;
|
|
|
|
else
|
|
|
|
patch->ws_rule = whitespace_rule(patch->new_name
|
|
|
|
? patch->new_name
|
|
|
|
: patch->old_name);
|
2007-12-06 08:14:14 +00:00
|
|
|
|
2016-05-24 08:10:50 +00:00
|
|
|
patchsize = parse_single_patch(state,
|
|
|
|
buffer + offset + hdrsize,
|
|
|
|
size - offset - hdrsize,
|
|
|
|
patch);
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2016-08-08 21:03:04 +00:00
|
|
|
if (patchsize < 0)
|
|
|
|
return -128;
|
|
|
|
|
2005-11-16 22:12:56 +00:00
|
|
|
if (!patchsize) {
|
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
|
|
|
static const char git_binary[] = "GIT binary patch\n";
|
2005-11-18 04:46:29 +00:00
|
|
|
int hd = hdrsize + offset;
|
|
|
|
unsigned long llen = linelen(buffer + hd, size - hd);
|
|
|
|
|
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 (llen == sizeof(git_binary) - 1 &&
|
|
|
|
!memcmp(git_binary, buffer + hd, llen)) {
|
|
|
|
int used;
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
|
|
|
used = parse_binary(state, buffer + hd + llen,
|
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
|
|
|
size - hd - llen, patch);
|
2016-03-18 12:30:41 +00:00
|
|
|
if (used < 0)
|
|
|
|
return -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
|
|
|
if (used)
|
|
|
|
patchsize = used + llen;
|
|
|
|
else
|
|
|
|
patchsize = 0;
|
|
|
|
}
|
|
|
|
else if (!memcmp(" differ\n", buffer + hd + llen - 8, 8)) {
|
2014-01-29 13:30:27 +00:00
|
|
|
static const char *binhdr[] = {
|
|
|
|
"Binary files ",
|
|
|
|
"Files ",
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
int i;
|
2005-11-18 04:46:29 +00:00
|
|
|
for (i = 0; binhdr[i]; i++) {
|
|
|
|
int len = strlen(binhdr[i]);
|
|
|
|
if (len < size - hd &&
|
|
|
|
!memcmp(binhdr[i], buffer + hd, len)) {
|
2016-05-24 08:11:20 +00:00
|
|
|
state->linenr++;
|
2005-11-18 04:46:29 +00:00
|
|
|
patch->is_binary = 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
|
|
|
patchsize = llen;
|
2005-11-18 04:46:29 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|
2005-11-09 22:59:23 +00:00
|
|
|
|
2006-09-07 05:45:21 +00:00
|
|
|
/* Empty patch cannot be applied if it is a text patch
|
|
|
|
* without metadata change. A binary patch appears
|
|
|
|
* empty to us here.
|
2005-11-16 22:12:56 +00:00
|
|
|
*/
|
2016-05-24 08:11:05 +00:00
|
|
|
if ((state->apply || state->check) &&
|
2016-08-08 21:03:03 +00:00
|
|
|
(!patch->is_binary && !metadata_changes(patch))) {
|
|
|
|
error(_("patch with only garbage at line %d"), state->linenr);
|
|
|
|
return -128;
|
|
|
|
}
|
2005-11-09 22:59:23 +00:00
|
|
|
}
|
2005-10-01 06:25:23 +00:00
|
|
|
|
2005-05-23 17:52:17 +00:00
|
|
|
return offset + hdrsize + patchsize;
|
|
|
|
}
|
|
|
|
|
2006-07-28 15:46:11 +00:00
|
|
|
#define swap(a,b) myswap((a),(b),sizeof(a))
|
|
|
|
|
|
|
|
#define myswap(a, b, size) do { \
|
|
|
|
unsigned char mytmp[size]; \
|
|
|
|
memcpy(mytmp, &a, size); \
|
|
|
|
memcpy(&a, &b, size); \
|
|
|
|
memcpy(&b, mytmp, size); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
static void reverse_patches(struct patch *p)
|
|
|
|
{
|
|
|
|
for (; p; p = p->next) {
|
|
|
|
struct fragment *frag = p->fragments;
|
|
|
|
|
|
|
|
swap(p->new_name, p->old_name);
|
|
|
|
swap(p->new_mode, p->old_mode);
|
|
|
|
swap(p->is_new, p->is_delete);
|
|
|
|
swap(p->lines_added, p->lines_deleted);
|
|
|
|
swap(p->old_sha1_prefix, p->new_sha1_prefix);
|
|
|
|
|
|
|
|
for (; frag; frag = frag->next) {
|
|
|
|
swap(frag->newpos, frag->oldpos);
|
|
|
|
swap(frag->newlines, frag->oldlines);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
static const char pluses[] =
|
|
|
|
"++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++";
|
|
|
|
static const char minuses[]=
|
|
|
|
"----------------------------------------------------------------------";
|
2005-05-26 18:40:43 +00:00
|
|
|
|
2016-05-24 08:11:19 +00:00
|
|
|
static void show_stats(struct apply_state *state, struct patch *patch)
|
2005-05-26 18:40:43 +00:00
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf qname = STRBUF_INIT;
|
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 *cp = patch->new_name ? patch->new_name : patch->old_name;
|
|
|
|
int max, add, del;
|
2005-05-26 18:40:43 +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
|
|
|
quote_c_style(cp, &qname, NULL, 0);
|
2005-10-15 04:54:52 +00:00
|
|
|
|
2005-05-26 18:40:43 +00:00
|
|
|
/*
|
|
|
|
* "scale" the filename
|
|
|
|
*/
|
2016-05-24 08:11:19 +00:00
|
|
|
max = state->max_len;
|
2005-05-26 18:40:43 +00:00
|
|
|
if (max > 50)
|
|
|
|
max = 50;
|
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 (qname.len > max) {
|
|
|
|
cp = strchr(qname.buf + qname.len + 3 - max, '/');
|
|
|
|
if (!cp)
|
|
|
|
cp = qname.buf + qname.len + 3 - max;
|
|
|
|
strbuf_splice(&qname, 0, cp - qname.buf, "...", 3);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (patch->is_binary) {
|
|
|
|
printf(" %-*s | Bin\n", max, qname.buf);
|
|
|
|
strbuf_release(&qname);
|
|
|
|
return;
|
2005-07-29 03:37:23 +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
|
|
|
|
|
|
|
printf(" %-*s |", max, qname.buf);
|
|
|
|
strbuf_release(&qname);
|
2005-05-26 18:40:43 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* scale the add/delete
|
|
|
|
*/
|
2016-05-24 08:11:19 +00:00
|
|
|
max = max + state->max_change > 70 ? 70 - max : state->max_change;
|
2005-06-01 03:50:49 +00:00
|
|
|
add = patch->lines_added;
|
|
|
|
del = patch->lines_deleted;
|
|
|
|
|
2016-05-24 08:11:19 +00:00
|
|
|
if (state->max_change > 0) {
|
|
|
|
int total = ((add + del) * max + state->max_change / 2) / state->max_change;
|
|
|
|
add = (add * max + state->max_change / 2) / state->max_change;
|
2005-06-21 15:14:30 +00:00
|
|
|
del = total - add;
|
|
|
|
}
|
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
|
|
|
printf("%5d %.*s%.*s\n", patch->lines_added + patch->lines_deleted,
|
|
|
|
add, pluses, del, minuses);
|
2005-05-26 18:40:43 +00:00
|
|
|
}
|
|
|
|
|
2007-09-16 16:54:42 +00:00
|
|
|
static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
|
|
|
switch (st->st_mode & S_IFMT) {
|
|
|
|
case S_IFLNK:
|
2008-12-17 17:36:40 +00:00
|
|
|
if (strbuf_readlink(buf, path, st->st_size) < 0)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("unable to read symlink %s"), path);
|
2007-09-16 16:54:42 +00:00
|
|
|
return 0;
|
2005-06-05 18:03:13 +00:00
|
|
|
case S_IFREG:
|
2007-09-27 13:25:55 +00:00
|
|
|
if (strbuf_read_file(buf, path, st->st_size) != st->st_size)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("unable to open or read %s"), path);
|
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
|
|
|
convert_to_git(path, buf->buf, buf->len, buf, 0);
|
2007-09-16 16:54:42 +00:00
|
|
|
return 0;
|
2005-06-05 18:03:13 +00:00
|
|
|
default:
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-08-04 11:16:49 +00:00
|
|
|
/*
|
|
|
|
* Update the preimage, and the common lines in postimage,
|
|
|
|
* from buffer buf of length len. If postlen is 0 the postimage
|
|
|
|
* is updated in place, otherwise it's updated on a new buffer
|
|
|
|
* of length postlen
|
|
|
|
*/
|
|
|
|
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
static void update_pre_post_images(struct image *preimage,
|
|
|
|
struct image *postimage,
|
|
|
|
char *buf,
|
2009-08-04 11:16:49 +00:00
|
|
|
size_t len, size_t postlen)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12 22:53:46 +00:00
|
|
|
int i, ctx, reduced;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
char *new, *old, *fixed;
|
|
|
|
struct image fixed_preimage;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
/*
|
|
|
|
* Update the preimage with whitespace fixes. Note that we
|
|
|
|
* are not losing preimage->buf -- apply_one_fragment() will
|
|
|
|
* free "oldlines".
|
|
|
|
*/
|
|
|
|
prepare_image(&fixed_preimage, buf, len, 1);
|
apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12 22:53:46 +00:00
|
|
|
assert(postlen
|
|
|
|
? fixed_preimage.nr == preimage->nr
|
|
|
|
: fixed_preimage.nr <= preimage->nr);
|
|
|
|
for (i = 0; i < fixed_preimage.nr; i++)
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
fixed_preimage.line[i].flag = preimage->line[i].flag;
|
|
|
|
free(preimage->line_allocated);
|
|
|
|
*preimage = fixed_preimage;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
/*
|
2009-08-04 11:16:49 +00:00
|
|
|
* Adjust the common context lines in postimage. This can be
|
2013-03-22 18:10:03 +00:00
|
|
|
* done in-place when we are shrinking it with whitespace
|
|
|
|
* fixing, but needs a new buffer when ignoring whitespace or
|
|
|
|
* expanding leading tabs to spaces.
|
|
|
|
*
|
2009-08-04 11:16:49 +00:00
|
|
|
* We trust the caller to tell us if the update can be done
|
|
|
|
* in place (postlen==0) or not.
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
*/
|
2009-08-04 11:16:49 +00:00
|
|
|
old = postimage->buf;
|
|
|
|
if (postlen)
|
|
|
|
new = postimage->buf = xmalloc(postlen);
|
|
|
|
else
|
|
|
|
new = old;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
fixed = preimage->buf;
|
apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12 22:53:46 +00:00
|
|
|
|
|
|
|
for (i = reduced = ctx = 0; i < postimage->nr; i++) {
|
2016-05-11 13:16:15 +00:00
|
|
|
size_t l_len = postimage->line[i].len;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
if (!(postimage->line[i].flag & LINE_COMMON)) {
|
|
|
|
/* an added line -- no counterparts in preimage */
|
2016-05-11 13:16:15 +00:00
|
|
|
memmove(new, old, l_len);
|
|
|
|
old += l_len;
|
|
|
|
new += l_len;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
continue;
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
|
|
|
/* a common context -- skip it in the original postimage */
|
2016-05-11 13:16:15 +00:00
|
|
|
old += l_len;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
|
|
|
/* and find the corresponding one in the fixed preimage */
|
|
|
|
while (ctx < preimage->nr &&
|
|
|
|
!(preimage->line[ctx].flag & LINE_COMMON)) {
|
|
|
|
fixed += preimage->line[ctx].len;
|
|
|
|
ctx++;
|
|
|
|
}
|
apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12 22:53:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* preimage is expected to run out, if the caller
|
|
|
|
* fixed addition of trailing blank lines.
|
|
|
|
*/
|
|
|
|
if (preimage->nr <= ctx) {
|
|
|
|
reduced++;
|
|
|
|
continue;
|
|
|
|
}
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
|
|
|
/* and copy it in, while fixing the line length */
|
2016-05-11 13:16:15 +00:00
|
|
|
l_len = preimage->line[ctx].len;
|
|
|
|
memcpy(new, fixed, l_len);
|
|
|
|
new += l_len;
|
|
|
|
fixed += l_len;
|
|
|
|
postimage->line[i].len = l_len;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
ctx++;
|
|
|
|
}
|
|
|
|
|
2015-01-16 19:54:47 +00:00
|
|
|
if (postlen
|
|
|
|
? postlen < new - postimage->buf
|
|
|
|
: postimage->len < new - postimage->buf)
|
|
|
|
die("BUG: caller miscounted postlen: asked %d, orig = %d, used = %d",
|
|
|
|
(int)postlen, (int) postimage->len, (int)(new - postimage->buf));
|
|
|
|
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
/* Fix the length of the whole thing */
|
|
|
|
postimage->len = new - postimage->buf;
|
apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught "git apply"
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a "fixed" patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12 22:53:46 +00:00
|
|
|
postimage->nr -= reduced;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
}
|
|
|
|
|
2016-05-11 13:16:16 +00:00
|
|
|
static int line_by_line_fuzzy_match(struct image *img,
|
|
|
|
struct image *preimage,
|
|
|
|
struct image *postimage,
|
|
|
|
unsigned long try,
|
|
|
|
int try_lno,
|
|
|
|
int preimage_limit)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
size_t imgoff = 0;
|
|
|
|
size_t preoff = 0;
|
|
|
|
size_t postlen = postimage->len;
|
|
|
|
size_t extra_chars;
|
|
|
|
char *buf;
|
|
|
|
char *preimage_eof;
|
|
|
|
char *preimage_end;
|
|
|
|
struct strbuf fixed;
|
|
|
|
char *fixed_buf;
|
|
|
|
size_t fixed_len;
|
|
|
|
|
|
|
|
for (i = 0; i < preimage_limit; i++) {
|
|
|
|
size_t prelen = preimage->line[i].len;
|
|
|
|
size_t imglen = img->line[try_lno+i].len;
|
|
|
|
|
|
|
|
if (!fuzzy_matchlines(img->buf + try + imgoff, imglen,
|
|
|
|
preimage->buf + preoff, prelen))
|
|
|
|
return 0;
|
|
|
|
if (preimage->line[i].flag & LINE_COMMON)
|
|
|
|
postlen += imglen - prelen;
|
|
|
|
imgoff += imglen;
|
|
|
|
preoff += prelen;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ok, the preimage matches with whitespace fuzz.
|
|
|
|
*
|
|
|
|
* imgoff now holds the true length of the target that
|
|
|
|
* matches the preimage before the end of the file.
|
|
|
|
*
|
|
|
|
* Count the number of characters in the preimage that fall
|
|
|
|
* beyond the end of the file and make sure that all of them
|
|
|
|
* are whitespace characters. (This can only happen if
|
|
|
|
* we are removing blank lines at the end of the file.)
|
|
|
|
*/
|
|
|
|
buf = preimage_eof = preimage->buf + preoff;
|
|
|
|
for ( ; i < preimage->nr; i++)
|
|
|
|
preoff += preimage->line[i].len;
|
|
|
|
preimage_end = preimage->buf + preoff;
|
|
|
|
for ( ; buf < preimage_end; buf++)
|
|
|
|
if (!isspace(*buf))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the preimage and the common postimage context
|
|
|
|
* lines to use the same whitespace as the target.
|
|
|
|
* If whitespace is missing in the target (i.e.
|
|
|
|
* if the preimage extends beyond the end of the file),
|
|
|
|
* use the whitespace from the preimage.
|
|
|
|
*/
|
|
|
|
extra_chars = preimage_end - preimage_eof;
|
|
|
|
strbuf_init(&fixed, imgoff + extra_chars);
|
|
|
|
strbuf_add(&fixed, img->buf + try, imgoff);
|
|
|
|
strbuf_add(&fixed, preimage_eof, extra_chars);
|
|
|
|
fixed_buf = strbuf_detach(&fixed, &fixed_len);
|
|
|
|
update_pre_post_images(preimage, postimage,
|
|
|
|
fixed_buf, fixed_len, postlen);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:17 +00:00
|
|
|
static int match_fragment(struct apply_state *state,
|
|
|
|
struct image *img,
|
2008-01-27 01:42:49 +00:00
|
|
|
struct image *preimage,
|
|
|
|
struct image *postimage,
|
2008-01-19 08:42:22 +00:00
|
|
|
unsigned long try,
|
2008-01-27 01:42:49 +00:00
|
|
|
int try_lno,
|
2008-01-30 23:13:37 +00:00
|
|
|
unsigned ws_rule,
|
2008-01-19 09:58:34 +00:00
|
|
|
int match_beginning, int match_end)
|
2008-01-19 08:42:22 +00:00
|
|
|
{
|
2008-01-27 01:42:49 +00:00
|
|
|
int i;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
char *fixed_buf, *buf, *orig, *target;
|
2010-04-02 23:37:23 +00:00
|
|
|
struct strbuf fixed;
|
2013-03-22 18:10:03 +00:00
|
|
|
size_t fixed_len, postlen;
|
2010-03-06 14:30:42 +00:00
|
|
|
int preimage_limit;
|
2008-01-27 01:42:49 +00:00
|
|
|
|
2010-03-06 14:30:42 +00:00
|
|
|
if (preimage->nr + try_lno <= img->nr) {
|
|
|
|
/*
|
|
|
|
* The hunk falls within the boundaries of img.
|
|
|
|
*/
|
|
|
|
preimage_limit = preimage->nr;
|
|
|
|
if (match_end && (preimage->nr + try_lno != img->nr))
|
|
|
|
return 0;
|
2016-05-24 08:11:17 +00:00
|
|
|
} else if (state->ws_error_action == correct_ws_error &&
|
2010-04-08 04:14:31 +00:00
|
|
|
(ws_rule & WS_BLANK_AT_EOF)) {
|
2010-03-06 14:30:42 +00:00
|
|
|
/*
|
2010-04-08 04:14:31 +00:00
|
|
|
* This hunk extends beyond the end of img, and we are
|
|
|
|
* removing blank lines at the end of the file. This
|
|
|
|
* many lines from the beginning of the preimage must
|
|
|
|
* match with img, and the remainder of the preimage
|
|
|
|
* must be blank.
|
2010-03-06 14:30:42 +00:00
|
|
|
*/
|
|
|
|
preimage_limit = img->nr - try_lno;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The hunk extends beyond the end of the img and
|
|
|
|
* we are not removing blanks at the end, so we
|
|
|
|
* should reject the hunk at this position.
|
|
|
|
*/
|
2008-01-27 01:42:49 +00:00
|
|
|
return 0;
|
2010-03-06 14:30:42 +00:00
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
|
|
|
|
if (match_beginning && try_lno)
|
2008-01-19 08:42:22 +00:00
|
|
|
return 0;
|
2008-01-19 09:58:34 +00:00
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
/* Quick hash check */
|
2010-03-06 14:30:42 +00:00
|
|
|
for (i = 0; i < preimage_limit; i++)
|
apply: do not patch lines that were already patched
When looking for a place to apply a hunk, we used to check lines that
match the preimage of it, starting from the line that the patch wants to
apply the hunk at, looking forward and backward with increasing offsets
until we find a match.
Colin Guthrie found an interesting case where this misapplied a patch that
wanted to touch a preimage that consists of
}
}
return 0;
}
which is a rather unfortunately common pattern.
The target version of the file originally had only one such location, but
the hunk immediately before that created another instance of such block of
lines, and find_pos() happily reported that the preimage of the hunk
matched what it wanted to modify.
Oops.
By marking the lines application of earlier hunks touched and preventing
match_fragment() from considering them as a match with preimage of other
hunks, we can reduce such an accident.
I also considered to teach apply_one_fragment() to take the offset we have
found while applying the previous hunk into account when looking for a
match with find_pos(), but dismissed that approach, because it would
sometimes work better but sometimes worse, depending on the difference
between the version the patch was created against and the version the
patch is being applied.
This does _not_ prevent misapplication of patches to a file that has many
similar looking blocks of lines and a preimage cannot identify which one
of them should be applied. For that, we would need to scan beyond the
first match in find_pos(), and issue a warning (or error out). That will
be a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-04 20:25:34 +00:00
|
|
|
if ((img->line[try_lno + i].flag & LINE_PATCHED) ||
|
|
|
|
(preimage->line[i].hash != img->line[try_lno + i].hash))
|
2008-01-27 01:42:49 +00:00
|
|
|
return 0;
|
|
|
|
|
2010-03-06 14:30:42 +00:00
|
|
|
if (preimage_limit == preimage->nr) {
|
|
|
|
/*
|
|
|
|
* Do we have an exact match? If we were told to match
|
|
|
|
* at the end, size must be exactly at try+fragsize,
|
|
|
|
* otherwise try+fragsize must be still within the preimage,
|
|
|
|
* and either case, the old piece should match the preimage
|
|
|
|
* exactly.
|
|
|
|
*/
|
|
|
|
if ((match_end
|
|
|
|
? (try + preimage->len == img->len)
|
|
|
|
: (try + preimage->len <= img->len)) &&
|
|
|
|
!memcmp(img->buf + try, preimage->buf, preimage->len))
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The preimage extends beyond the end of img, so
|
|
|
|
* there cannot be an exact match.
|
|
|
|
*
|
|
|
|
* There must be one non-blank context line that match
|
|
|
|
* a line before the end of img.
|
|
|
|
*/
|
|
|
|
char *buf_end;
|
|
|
|
|
|
|
|
buf = preimage->buf;
|
|
|
|
buf_end = buf;
|
|
|
|
for (i = 0; i < preimage_limit; i++)
|
|
|
|
buf_end += preimage->line[i].len;
|
|
|
|
|
|
|
|
for ( ; buf < buf_end; buf++)
|
|
|
|
if (!isspace(*buf))
|
|
|
|
break;
|
|
|
|
if (buf == buf_end)
|
|
|
|
return 0;
|
|
|
|
}
|
2008-01-19 09:58:34 +00:00
|
|
|
|
2009-08-04 11:16:49 +00:00
|
|
|
/*
|
|
|
|
* No exact match. If we are ignoring whitespace, run a line-by-line
|
|
|
|
* fuzzy matching. We collect all the line length information because
|
|
|
|
* we need it to adjust whitespace if we match.
|
|
|
|
*/
|
2016-05-24 08:11:18 +00:00
|
|
|
if (state->ws_ignore_action == ignore_ws_change)
|
2016-05-11 13:16:16 +00:00
|
|
|
return line_by_line_fuzzy_match(img, preimage, postimage,
|
|
|
|
try, try_lno, preimage_limit);
|
2009-08-04 11:16:49 +00:00
|
|
|
|
2016-05-24 08:11:17 +00:00
|
|
|
if (state->ws_error_action != correct_ws_error)
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
return 0;
|
|
|
|
|
2008-01-19 09:58:34 +00:00
|
|
|
/*
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
* The hunk does not apply byte-by-byte, but the hash says
|
2015-01-16 21:54:52 +00:00
|
|
|
* it might with whitespace fuzz. We weren't asked to
|
2009-08-04 11:16:49 +00:00
|
|
|
* ignore whitespace, we were asked to correct whitespace
|
|
|
|
* errors, so let's try matching after whitespace correction.
|
2010-03-06 14:30:42 +00:00
|
|
|
*
|
apply: count the size of postimage correctly
Under --whitespace=fix option, match_fragment() function examines
the preimage (the common context and the removed lines in the patch)
and the file being patched and checks if they match after correcting
all whitespace errors. When they are found to match, the common
context lines in the preimage is replaced with the fixed copy,
because these lines will then be copied to the corresponding place
in the postimage by a later call to update_pre_post_images(). Lines
that are added in the postimage, under --whitespace=fix, have their
whitespace errors already fixed when apply_one_fragment() prepares
the preimage and the postimage, so in the end, application of the
patch can be done by replacing the block of text in the file being
patched that matched the preimage with what is in the postimage that
was updated by update_pre_post_images().
In the earlier days, fixing whitespace errors always resulted in
reduction of size, either collapsing runs of spaces in the indent to
a tab or removing the trailing whitespaces. These days, however,
some whitespace error fix results in extending the size.
250b3c6c (apply --whitespace=fix: avoid running over the postimage
buffer, 2013-03-22) tried to compute the final postimage size but
its math was flawed. It counted the size of the block of text in
the original being patched after fixing the whitespace errors on its
lines that correspond to the preimage. That number does not have
much to do with how big the final postimage would be.
Instead count (1) the added lines in the postimage, whose size is
the same as in the final patch result because their whitespace
errors have already been corrected, and (2) the fixed size of the
lines that are common.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16 23:32:00 +00:00
|
|
|
* While checking the preimage against the target, whitespace
|
|
|
|
* errors in both fixed, we count how large the corresponding
|
|
|
|
* postimage needs to be. The postimage prepared by
|
|
|
|
* apply_one_fragment() has whitespace errors fixed on added
|
|
|
|
* lines already, but the common lines were propagated as-is,
|
|
|
|
* which may become longer when their whitespace errors are
|
|
|
|
* fixed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* First count added lines in postimage */
|
|
|
|
postlen = 0;
|
|
|
|
for (i = 0; i < postimage->nr; i++) {
|
|
|
|
if (!(postimage->line[i].flag & LINE_COMMON))
|
|
|
|
postlen += postimage->line[i].len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-03-06 14:30:42 +00:00
|
|
|
* The preimage may extend beyond the end of the file,
|
|
|
|
* but in this loop we will only handle the part of the
|
|
|
|
* preimage that falls within the file.
|
2008-01-19 09:58:34 +00:00
|
|
|
*/
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_init(&fixed, preimage->len + 1);
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
orig = preimage->buf;
|
|
|
|
target = img->buf + try;
|
2010-03-06 14:30:42 +00:00
|
|
|
for (i = 0; i < preimage_limit; i++) {
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
size_t oldlen = preimage->line[i].len;
|
|
|
|
size_t tgtlen = img->line[try_lno + i].len;
|
2010-04-02 23:37:23 +00:00
|
|
|
size_t fixstart = fixed.len;
|
|
|
|
struct strbuf tgtfix;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
int match;
|
|
|
|
|
|
|
|
/* Try fixing the line in the preimage */
|
2010-04-02 23:37:23 +00:00
|
|
|
ws_fix_copy(&fixed, orig, oldlen, ws_rule, NULL);
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
|
|
|
/* Try fixing the line in the target */
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_init(&tgtfix, tgtlen);
|
|
|
|
ws_fix_copy(&tgtfix, target, tgtlen, ws_rule, NULL);
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If they match, either the preimage was based on
|
|
|
|
* a version before our tree fixed whitespace breakage,
|
|
|
|
* or we are lacking a whitespace-fix patch the tree
|
|
|
|
* the preimage was based on already had (i.e. target
|
|
|
|
* has whitespace breakage, the preimage doesn't).
|
|
|
|
* In either case, we are fixing the whitespace breakages
|
|
|
|
* so we might as well take the fix together with their
|
|
|
|
* real change.
|
|
|
|
*/
|
2010-04-02 23:37:23 +00:00
|
|
|
match = (tgtfix.len == fixed.len - fixstart &&
|
|
|
|
!memcmp(tgtfix.buf, fixed.buf + fixstart,
|
|
|
|
fixed.len - fixstart));
|
apply: count the size of postimage correctly
Under --whitespace=fix option, match_fragment() function examines
the preimage (the common context and the removed lines in the patch)
and the file being patched and checks if they match after correcting
all whitespace errors. When they are found to match, the common
context lines in the preimage is replaced with the fixed copy,
because these lines will then be copied to the corresponding place
in the postimage by a later call to update_pre_post_images(). Lines
that are added in the postimage, under --whitespace=fix, have their
whitespace errors already fixed when apply_one_fragment() prepares
the preimage and the postimage, so in the end, application of the
patch can be done by replacing the block of text in the file being
patched that matched the preimage with what is in the postimage that
was updated by update_pre_post_images().
In the earlier days, fixing whitespace errors always resulted in
reduction of size, either collapsing runs of spaces in the indent to
a tab or removing the trailing whitespaces. These days, however,
some whitespace error fix results in extending the size.
250b3c6c (apply --whitespace=fix: avoid running over the postimage
buffer, 2013-03-22) tried to compute the final postimage size but
its math was flawed. It counted the size of the block of text in
the original being patched after fixing the whitespace errors on its
lines that correspond to the preimage. That number does not have
much to do with how big the final postimage would be.
Instead count (1) the added lines in the postimage, whose size is
the same as in the final patch result because their whitespace
errors have already been corrected, and (2) the fixed size of the
lines that are common.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16 23:32:00 +00:00
|
|
|
|
|
|
|
/* Add the length if this is common with the postimage */
|
|
|
|
if (preimage->line[i].flag & LINE_COMMON)
|
|
|
|
postlen += tgtfix.len;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_release(&tgtfix);
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
if (!match)
|
|
|
|
goto unmatch_exit;
|
|
|
|
|
|
|
|
orig += oldlen;
|
|
|
|
target += tgtlen;
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
|
|
|
|
2010-03-06 14:30:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now handle the lines in the preimage that falls beyond the
|
|
|
|
* end of the file (if any). They will only match if they are
|
|
|
|
* empty or only contain whitespace (if WS_BLANK_AT_EOL is
|
|
|
|
* false).
|
|
|
|
*/
|
|
|
|
for ( ; i < preimage->nr; i++) {
|
2010-04-02 23:37:23 +00:00
|
|
|
size_t fixstart = fixed.len; /* start of the fixed preimage */
|
2010-03-06 14:30:42 +00:00
|
|
|
size_t oldlen = preimage->line[i].len;
|
|
|
|
int j;
|
|
|
|
|
|
|
|
/* Try fixing the line in the preimage */
|
2010-04-02 23:37:23 +00:00
|
|
|
ws_fix_copy(&fixed, orig, oldlen, ws_rule, NULL);
|
2010-03-06 14:30:42 +00:00
|
|
|
|
2010-04-02 23:37:23 +00:00
|
|
|
for (j = fixstart; j < fixed.len; j++)
|
|
|
|
if (!isspace(fixed.buf[j]))
|
2010-03-06 14:30:42 +00:00
|
|
|
goto unmatch_exit;
|
|
|
|
|
|
|
|
orig += oldlen;
|
|
|
|
}
|
|
|
|
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
/*
|
|
|
|
* Yes, the preimage is based on an older version that still
|
|
|
|
* has whitespace breakages unfixed, and fixing them makes the
|
|
|
|
* hunk match. Update the context lines in the postimage.
|
|
|
|
*/
|
2010-04-02 23:37:23 +00:00
|
|
|
fixed_buf = strbuf_detach(&fixed, &fixed_len);
|
2013-03-22 18:10:03 +00:00
|
|
|
if (postlen < postimage->len)
|
|
|
|
postlen = 0;
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
update_pre_post_images(preimage, postimage,
|
2013-03-22 18:10:03 +00:00
|
|
|
fixed_buf, fixed_len, postlen);
|
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-30 23:24:34 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
unmatch_exit:
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_release(&fixed);
|
2008-01-19 09:58:34 +00:00
|
|
|
return 0;
|
2008-01-19 08:42:22 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:17 +00:00
|
|
|
static int find_pos(struct apply_state *state,
|
|
|
|
struct image *img,
|
2008-01-27 01:42:49 +00:00
|
|
|
struct image *preimage,
|
|
|
|
struct image *postimage,
|
|
|
|
int line,
|
2008-01-30 23:13:37 +00:00
|
|
|
unsigned ws_rule,
|
2008-01-27 01:42:49 +00:00
|
|
|
int match_beginning, int match_end)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
2008-01-27 01:42:49 +00:00
|
|
|
int i;
|
|
|
|
unsigned long backwards, forwards, try;
|
|
|
|
int backwards_lno, forwards_lno, try_lno;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
2008-01-28 11:04:30 +00:00
|
|
|
/*
|
apply: Remove the quick rejection test
In the next commit, we will make it possible for blank context
lines to match beyond the end of the file. That means that a hunk
with a preimage that has more lines than present in the file may
be possible to successfully apply. Therefore, we must remove
the quick rejection test in find_pos().
find_pos() will already work correctly without the quick
rejection test, but that might not be obvious. Therefore,
comment the test for handling out-of-range line numbers in
find_pos() and cast the "line" variable to the same (unsigned)
type as img->nr.
What are performance implications of removing the quick
rejection test?
It can only help "git apply" to reject a patch faster. For example,
if I have a file with one million lines and a patch that removes
slightly more than 50 percent of the lines and try to apply that
patch twice, the second attempt will fail slightly faster
with the test than without (based on actual measurements).
However, there is the pathological case of a patch with many
more context lines than the default three, and applying that patch
using "git apply -C1". Without the rejection test, the running
time will be roughly proportional to the number of context lines
times the size of the file. That could be handled by writing
a more complicated rejection test (it would have to count the
number of blanks at the end of the preimage), but I don't find
that worth doing until there is a real-world use case that
would benfit from it.
It would be possible to keep the quick rejection test if
--whitespace=fix is not given, but I don't like that from
a testing point of view.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06 14:30:29 +00:00
|
|
|
* If match_beginning or match_end is specified, there is no
|
2008-01-28 11:04:30 +00:00
|
|
|
* point starting from a wrong line that will never match and
|
|
|
|
* wander around and wait for a match at the specified end.
|
|
|
|
*/
|
|
|
|
if (match_beginning)
|
|
|
|
line = 0;
|
|
|
|
else if (match_end)
|
|
|
|
line = img->nr - preimage->nr;
|
|
|
|
|
apply: Remove the quick rejection test
In the next commit, we will make it possible for blank context
lines to match beyond the end of the file. That means that a hunk
with a preimage that has more lines than present in the file may
be possible to successfully apply. Therefore, we must remove
the quick rejection test in find_pos().
find_pos() will already work correctly without the quick
rejection test, but that might not be obvious. Therefore,
comment the test for handling out-of-range line numbers in
find_pos() and cast the "line" variable to the same (unsigned)
type as img->nr.
What are performance implications of removing the quick
rejection test?
It can only help "git apply" to reject a patch faster. For example,
if I have a file with one million lines and a patch that removes
slightly more than 50 percent of the lines and try to apply that
patch twice, the second attempt will fail slightly faster
with the test than without (based on actual measurements).
However, there is the pathological case of a patch with many
more context lines than the default three, and applying that patch
using "git apply -C1". Without the rejection test, the running
time will be roughly proportional to the number of context lines
times the size of the file. That could be handled by writing
a more complicated rejection test (it would have to count the
number of blanks at the end of the preimage), but I don't find
that worth doing until there is a real-world use case that
would benfit from it.
It would be possible to keep the quick rejection test if
--whitespace=fix is not given, but I don't like that from
a testing point of view.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06 14:30:29 +00:00
|
|
|
/*
|
|
|
|
* Because the comparison is unsigned, the following test
|
|
|
|
* will also take care of a negative line number that can
|
|
|
|
* result when match_end and preimage is larger than the target.
|
|
|
|
*/
|
|
|
|
if ((size_t) line > img->nr)
|
2008-02-11 23:32:29 +00:00
|
|
|
line = img->nr;
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
try = 0;
|
|
|
|
for (i = 0; i < line; i++)
|
|
|
|
try += img->line[i].len;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
2005-06-05 19:16:32 +00:00
|
|
|
/*
|
|
|
|
* There's probably some smart way to do this, but I'll leave
|
|
|
|
* that to the smart and beautiful people. I'm simple and stupid.
|
|
|
|
*/
|
2008-01-27 01:42:49 +00:00
|
|
|
backwards = try;
|
|
|
|
backwards_lno = line;
|
|
|
|
forwards = try;
|
|
|
|
forwards_lno = line;
|
|
|
|
try_lno = line;
|
2008-01-19 10:16:16 +00:00
|
|
|
|
2005-06-05 19:16:32 +00:00
|
|
|
for (i = 0; ; i++) {
|
2016-05-24 08:11:17 +00:00
|
|
|
if (match_fragment(state, img, preimage, postimage,
|
2008-01-30 23:13:37 +00:00
|
|
|
try, try_lno, ws_rule,
|
2008-01-27 01:42:49 +00:00
|
|
|
match_beginning, match_end))
|
|
|
|
return try_lno;
|
2008-01-19 10:16:16 +00:00
|
|
|
|
|
|
|
again:
|
2008-01-27 01:42:49 +00:00
|
|
|
if (backwards_lno == 0 && forwards_lno == img->nr)
|
2008-01-19 10:16:16 +00:00
|
|
|
break;
|
2005-06-05 19:16:32 +00:00
|
|
|
|
|
|
|
if (i & 1) {
|
2008-01-27 01:42:49 +00:00
|
|
|
if (backwards_lno == 0) {
|
2008-01-19 10:16:16 +00:00
|
|
|
i++;
|
|
|
|
goto again;
|
2005-06-05 19:16:32 +00:00
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
backwards_lno--;
|
|
|
|
backwards -= img->line[backwards_lno].len;
|
2005-06-05 19:16:32 +00:00
|
|
|
try = backwards;
|
2008-01-27 01:42:49 +00:00
|
|
|
try_lno = backwards_lno;
|
2005-06-05 19:16:32 +00:00
|
|
|
} else {
|
2008-01-27 01:42:49 +00:00
|
|
|
if (forwards_lno == img->nr) {
|
2008-01-19 10:16:16 +00:00
|
|
|
i++;
|
|
|
|
goto again;
|
2005-06-05 19:16:32 +00:00
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
forwards += img->line[forwards_lno].len;
|
|
|
|
forwards_lno++;
|
2005-06-05 19:16:32 +00:00
|
|
|
try = forwards;
|
2008-01-27 01:42:49 +00:00
|
|
|
try_lno = forwards_lno;
|
2005-06-05 19:16:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
static void remove_first_line(struct image *img)
|
2006-04-10 09:33:06 +00:00
|
|
|
{
|
2008-01-27 01:42:49 +00:00
|
|
|
img->buf += img->line[0].len;
|
|
|
|
img->len -= img->line[0].len;
|
|
|
|
img->line++;
|
|
|
|
img->nr--;
|
2006-04-10 09:33:06 +00:00
|
|
|
}
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
static void remove_last_line(struct image *img)
|
2006-04-10 09:33:06 +00:00
|
|
|
{
|
2008-01-27 01:42:49 +00:00
|
|
|
img->len -= img->line[--img->nr].len;
|
2006-04-10 09:33:06 +00:00
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* The change from "preimage" and "postimage" has been found to
|
|
|
|
* apply at applied_pos (counts in line numbers) in "img".
|
|
|
|
* Update "img" to remove "preimage" and replace it with "postimage".
|
|
|
|
*/
|
2016-05-24 08:10:54 +00:00
|
|
|
static void update_image(struct apply_state *state,
|
|
|
|
struct image *img,
|
2008-01-27 01:42:49 +00:00
|
|
|
int applied_pos,
|
|
|
|
struct image *preimage,
|
|
|
|
struct image *postimage)
|
2006-02-27 02:13:25 +00:00
|
|
|
{
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
2008-01-27 01:42:49 +00:00
|
|
|
* remove the copy of preimage at offset in img
|
|
|
|
* and replace it with postimage
|
2007-11-23 10:37:03 +00:00
|
|
|
*/
|
2008-01-27 01:42:49 +00:00
|
|
|
int i, nr;
|
|
|
|
size_t remove_count, insert_count, applied_at = 0;
|
|
|
|
char *result;
|
2010-03-06 14:30:42 +00:00
|
|
|
int preimage_limit;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are removing blank lines at the end of img,
|
|
|
|
* the preimage may extend beyond the end.
|
|
|
|
* If that is the case, we must be careful only to
|
|
|
|
* remove the part of the preimage that falls within
|
|
|
|
* the boundaries of img. Initialize preimage_limit
|
|
|
|
* to the number of lines in the preimage that falls
|
|
|
|
* within the boundaries.
|
|
|
|
*/
|
|
|
|
preimage_limit = preimage->nr;
|
|
|
|
if (preimage_limit > img->nr - applied_pos)
|
|
|
|
preimage_limit = img->nr - applied_pos;
|
2007-11-24 04:14:20 +00:00
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
for (i = 0; i < applied_pos; i++)
|
|
|
|
applied_at += img->line[i].len;
|
|
|
|
|
|
|
|
remove_count = 0;
|
2010-03-06 14:30:42 +00:00
|
|
|
for (i = 0; i < preimage_limit; i++)
|
2008-01-27 01:42:49 +00:00
|
|
|
remove_count += img->line[applied_pos + i].len;
|
|
|
|
insert_count = postimage->len;
|
|
|
|
|
|
|
|
/* Adjust the contents */
|
2016-02-22 22:44:35 +00:00
|
|
|
result = xmalloc(st_add3(st_sub(img->len, remove_count), insert_count, 1));
|
2008-01-27 01:42:49 +00:00
|
|
|
memcpy(result, img->buf, applied_at);
|
|
|
|
memcpy(result + applied_at, postimage->buf, postimage->len);
|
|
|
|
memcpy(result + applied_at + postimage->len,
|
|
|
|
img->buf + (applied_at + remove_count),
|
|
|
|
img->len - (applied_at + remove_count));
|
|
|
|
free(img->buf);
|
|
|
|
img->buf = result;
|
|
|
|
img->len += insert_count - remove_count;
|
|
|
|
result[img->len] = '\0';
|
|
|
|
|
|
|
|
/* Adjust the line table */
|
2010-03-06 14:30:42 +00:00
|
|
|
nr = img->nr + postimage->nr - preimage_limit;
|
|
|
|
if (preimage_limit < postimage->nr) {
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
2008-01-27 01:42:49 +00:00
|
|
|
* NOTE: this knows that we never call remove_first_line()
|
|
|
|
* on anything other than pre/post image.
|
2006-09-23 07:37:19 +00:00
|
|
|
*/
|
2014-09-16 18:56:57 +00:00
|
|
|
REALLOC_ARRAY(img->line, nr);
|
2008-01-27 01:42:49 +00:00
|
|
|
img->line_allocated = img->line;
|
2006-09-23 07:37:19 +00:00
|
|
|
}
|
2010-03-06 14:30:42 +00:00
|
|
|
if (preimage_limit != postimage->nr)
|
2008-01-27 01:42:49 +00:00
|
|
|
memmove(img->line + applied_pos + postimage->nr,
|
2010-03-06 14:30:42 +00:00
|
|
|
img->line + applied_pos + preimage_limit,
|
|
|
|
(img->nr - (applied_pos + preimage_limit)) *
|
2008-01-27 01:42:49 +00:00
|
|
|
sizeof(*img->line));
|
|
|
|
memcpy(img->line + applied_pos,
|
|
|
|
postimage->line,
|
|
|
|
postimage->nr * sizeof(*img->line));
|
2016-05-24 08:10:54 +00:00
|
|
|
if (!state->allow_overlap)
|
2011-04-06 21:20:57 +00:00
|
|
|
for (i = 0; i < postimage->nr; i++)
|
|
|
|
img->line[applied_pos + i].flag |= LINE_PATCHED;
|
2008-01-27 01:42:49 +00:00
|
|
|
img->nr = nr;
|
2006-02-27 02:13:25 +00:00
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* Use the patch-hunk text in "frag" to prepare two images (preimage and
|
|
|
|
* postimage) for the hunk. Find lines that match "preimage" in "img" and
|
|
|
|
* replace the part of "img" with "postimage" text.
|
|
|
|
*/
|
2016-05-24 08:10:47 +00:00
|
|
|
static int apply_one_fragment(struct apply_state *state,
|
|
|
|
struct image *img, struct fragment *frag,
|
2011-03-04 22:43:45 +00:00
|
|
|
int inaccurate_eof, unsigned ws_rule,
|
|
|
|
int nth_fragment)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
2006-05-24 20:19:50 +00:00
|
|
|
int match_beginning, match_end;
|
2005-06-05 18:03:13 +00:00
|
|
|
const char *patch = frag->patch;
|
2008-01-27 01:42:49 +00:00
|
|
|
int size = frag->size;
|
2010-04-02 23:37:23 +00:00
|
|
|
char *old, *oldlines;
|
|
|
|
struct strbuf newlines;
|
2007-05-21 06:51:06 +00:00
|
|
|
int new_blank_lines_at_end = 0;
|
2011-09-26 20:30:30 +00:00
|
|
|
int found_new_blank_lines_at_end = 0;
|
|
|
|
int hunk_linenr = frag->linenr;
|
2006-04-10 09:33:06 +00:00
|
|
|
unsigned long leading, trailing;
|
2008-01-27 01:42:49 +00:00
|
|
|
int pos, applied_pos;
|
|
|
|
struct image preimage;
|
|
|
|
struct image postimage;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
2008-01-29 08:17:55 +00:00
|
|
|
memset(&preimage, 0, sizeof(preimage));
|
|
|
|
memset(&postimage, 0, sizeof(postimage));
|
2008-01-30 21:12:25 +00:00
|
|
|
oldlines = xmalloc(size);
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_init(&newlines, size);
|
2008-01-29 08:17:55 +00:00
|
|
|
|
2008-01-30 21:12:25 +00:00
|
|
|
old = oldlines;
|
2005-06-05 18:03:13 +00:00
|
|
|
while (size > 0) {
|
2006-07-28 15:46:11 +00:00
|
|
|
char first;
|
2005-06-05 18:03:13 +00:00
|
|
|
int len = linelen(patch, size);
|
2010-04-02 23:37:23 +00:00
|
|
|
int plen;
|
2007-05-21 06:51:06 +00:00
|
|
|
int added_blank_line = 0;
|
apply --whitespace=fix: detect new blank lines at eof correctly
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 21:08:20 +00:00
|
|
|
int is_blank_context = 0;
|
2010-04-02 23:37:23 +00:00
|
|
|
size_t start;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
|
|
|
if (!len)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "plen" is how much of the line we should use for
|
|
|
|
* the actual patch data. Normally we just remove the
|
|
|
|
* first character on the line, but if the line is
|
|
|
|
* followed by "\ No newline", then we also remove the
|
|
|
|
* last one (which is the newline, of course).
|
|
|
|
*/
|
2008-01-30 21:12:25 +00:00
|
|
|
plen = len - 1;
|
2005-07-22 16:56:39 +00:00
|
|
|
if (len < size && patch[len] == '\\')
|
2005-06-05 18:03:13 +00:00
|
|
|
plen--;
|
2006-07-28 15:46:11 +00:00
|
|
|
first = *patch;
|
2016-05-24 08:10:50 +00:00
|
|
|
if (state->apply_in_reverse) {
|
2006-07-28 15:46:11 +00:00
|
|
|
if (first == '-')
|
|
|
|
first = '+';
|
|
|
|
else if (first == '+')
|
|
|
|
first = '-';
|
|
|
|
}
|
2007-05-20 12:45:59 +00:00
|
|
|
|
2006-07-28 15:46:11 +00:00
|
|
|
switch (first) {
|
2006-10-20 02:26:08 +00:00
|
|
|
case '\n':
|
|
|
|
/* Newer GNU diff, empty context line */
|
|
|
|
if (plen < 0)
|
|
|
|
/* ... followed by '\No newline'; nothing */
|
|
|
|
break;
|
2008-01-30 21:12:25 +00:00
|
|
|
*old++ = '\n';
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_addch(&newlines, '\n');
|
2008-01-29 08:17:55 +00:00
|
|
|
add_line_info(&preimage, "\n", 1, LINE_COMMON);
|
|
|
|
add_line_info(&postimage, "\n", 1, LINE_COMMON);
|
apply --whitespace=fix: detect new blank lines at eof correctly
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 21:08:20 +00:00
|
|
|
is_blank_context = 1;
|
2006-10-20 02:26:08 +00:00
|
|
|
break;
|
2005-06-05 18:03:13 +00:00
|
|
|
case ' ':
|
2009-09-04 09:25:57 +00:00
|
|
|
if (plen && (ws_rule & WS_BLANK_AT_EOF) &&
|
|
|
|
ws_blank_line(patch + 1, plen, ws_rule))
|
apply --whitespace=fix: detect new blank lines at eof correctly
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 21:08:20 +00:00
|
|
|
is_blank_context = 1;
|
2005-06-05 18:03:13 +00:00
|
|
|
case '-':
|
2008-01-30 21:12:25 +00:00
|
|
|
memcpy(old, patch + 1, plen);
|
|
|
|
add_line_info(&preimage, old, plen,
|
2008-01-29 08:17:55 +00:00
|
|
|
(first == ' ' ? LINE_COMMON : 0));
|
2008-01-30 21:12:25 +00:00
|
|
|
old += plen;
|
2006-07-28 15:46:11 +00:00
|
|
|
if (first == '-')
|
2005-06-05 18:03:13 +00:00
|
|
|
break;
|
|
|
|
/* Fall-through for ' ' */
|
|
|
|
case '+':
|
2008-01-30 21:19:58 +00:00
|
|
|
/* --no-add does not add new lines */
|
2016-05-24 08:11:00 +00:00
|
|
|
if (first == '+' && state->no_add)
|
2008-01-30 21:19:58 +00:00
|
|
|
break;
|
|
|
|
|
2010-04-02 23:37:23 +00:00
|
|
|
start = newlines.len;
|
2008-01-30 21:19:58 +00:00
|
|
|
if (first != '+' ||
|
2016-05-24 08:11:12 +00:00
|
|
|
!state->whitespace_error ||
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action != correct_ws_error) {
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_add(&newlines, patch + 1, plen);
|
2008-01-30 21:19:58 +00:00
|
|
|
}
|
|
|
|
else {
|
2016-05-24 08:11:16 +00:00
|
|
|
ws_fix_copy(&newlines, patch + 1, plen, ws_rule, &state->applied_after_fixing_ws);
|
2007-05-21 06:51:06 +00:00
|
|
|
}
|
2010-04-02 23:37:23 +00:00
|
|
|
add_line_info(&postimage, newlines.buf + start, newlines.len - start,
|
2008-01-30 21:19:58 +00:00
|
|
|
(first == '+' ? 0 : LINE_COMMON));
|
|
|
|
if (first == '+' &&
|
2009-09-04 09:25:57 +00:00
|
|
|
(ws_rule & WS_BLANK_AT_EOF) &&
|
|
|
|
ws_blank_line(patch + 1, plen, ws_rule))
|
2008-01-30 21:19:58 +00:00
|
|
|
added_blank_line = 1;
|
2005-06-05 18:03:13 +00:00
|
|
|
break;
|
|
|
|
case '@': case '\\':
|
|
|
|
/* Ignore it, we already handled it */
|
|
|
|
break;
|
|
|
|
default:
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely)
|
2012-04-23 12:30:27 +00:00
|
|
|
error(_("invalid start of line: '%c'"), first);
|
2015-03-21 00:28:02 +00:00
|
|
|
applied_pos = -1;
|
|
|
|
goto out;
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
2011-09-26 20:30:30 +00:00
|
|
|
if (added_blank_line) {
|
|
|
|
if (!new_blank_lines_at_end)
|
|
|
|
found_new_blank_lines_at_end = hunk_linenr;
|
2007-05-21 06:51:06 +00:00
|
|
|
new_blank_lines_at_end++;
|
2011-09-26 20:30:30 +00:00
|
|
|
}
|
apply --whitespace=fix: detect new blank lines at eof correctly
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 21:08:20 +00:00
|
|
|
else if (is_blank_context)
|
|
|
|
;
|
2007-05-21 06:51:06 +00:00
|
|
|
else
|
|
|
|
new_blank_lines_at_end = 0;
|
2005-06-05 18:03:13 +00:00
|
|
|
patch += len;
|
|
|
|
size -= len;
|
2011-09-26 20:30:30 +00:00
|
|
|
hunk_linenr++;
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
2007-11-23 10:37:03 +00:00
|
|
|
if (inaccurate_eof &&
|
2008-01-30 21:12:25 +00:00
|
|
|
old > oldlines && old[-1] == '\n' &&
|
2010-04-02 23:37:23 +00:00
|
|
|
newlines.len > 0 && newlines.buf[newlines.len - 1] == '\n') {
|
2008-01-30 21:12:25 +00:00
|
|
|
old--;
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_setlen(&newlines, newlines.len - 1);
|
2006-02-17 14:23:16 +00:00
|
|
|
}
|
2006-04-10 09:33:06 +00:00
|
|
|
|
|
|
|
leading = frag->leading;
|
|
|
|
trailing = frag->trailing;
|
2006-05-24 02:08:01 +00:00
|
|
|
|
|
|
|
/*
|
2008-04-07 02:21:45 +00:00
|
|
|
* A hunk to change lines at the beginning would begin with
|
|
|
|
* @@ -1,L +N,M @@
|
2008-08-30 20:20:31 +00:00
|
|
|
* but we need to be careful. -U0 that inserts before the second
|
|
|
|
* line also has this pattern.
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
*
|
2008-04-07 02:21:45 +00:00
|
|
|
* And a hunk to add to an empty file would begin with
|
|
|
|
* @@ -0,0 +N,M @@
|
|
|
|
*
|
|
|
|
* In other words, a hunk that is (frag->oldpos <= 1) with or
|
|
|
|
* without leading context must match at the beginning.
|
2006-05-24 02:08:01 +00:00
|
|
|
*/
|
2008-08-30 20:20:31 +00:00
|
|
|
match_beginning = (!frag->oldpos ||
|
2016-05-24 08:10:47 +00:00
|
|
|
(frag->oldpos == 1 && !state->unidiff_zero));
|
2008-04-07 02:21:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A hunk without trailing lines must match at the end.
|
|
|
|
* However, we simply cannot tell if a hunk must match end
|
|
|
|
* from the lack of trailing lines if the patch was generated
|
|
|
|
* with unidiff without any context.
|
|
|
|
*/
|
2016-05-24 08:10:47 +00:00
|
|
|
match_end = !state->unidiff_zero && !trailing;
|
2006-05-24 02:08:01 +00:00
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
pos = frag->newpos ? (frag->newpos - 1) : 0;
|
2008-01-30 21:12:25 +00:00
|
|
|
preimage.buf = oldlines;
|
|
|
|
preimage.len = old - oldlines;
|
2010-04-02 23:37:23 +00:00
|
|
|
postimage.buf = newlines.buf;
|
|
|
|
postimage.len = newlines.len;
|
2008-01-29 08:17:55 +00:00
|
|
|
preimage.line = preimage.line_allocated;
|
|
|
|
postimage.line = postimage.line_allocated;
|
|
|
|
|
2006-04-10 09:33:06 +00:00
|
|
|
for (;;) {
|
2007-05-20 12:45:59 +00:00
|
|
|
|
2016-05-24 08:11:17 +00:00
|
|
|
applied_pos = find_pos(state, img, &preimage, &postimage, pos,
|
2008-01-30 23:13:37 +00:00
|
|
|
ws_rule, match_beginning, match_end);
|
2008-01-27 01:42:49 +00:00
|
|
|
|
|
|
|
if (applied_pos >= 0)
|
2006-04-10 09:33:06 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* Am I at my context limits? */
|
2016-05-24 08:11:04 +00:00
|
|
|
if ((leading <= state->p_context) && (trailing <= state->p_context))
|
2006-04-10 09:33:06 +00:00
|
|
|
break;
|
2006-05-24 20:19:50 +00:00
|
|
|
if (match_beginning || match_end) {
|
|
|
|
match_beginning = match_end = 0;
|
2006-05-24 02:08:01 +00:00
|
|
|
continue;
|
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* Reduce the number of context lines; reduce both
|
|
|
|
* leading and trailing if they are equal otherwise
|
|
|
|
* just reduce the larger context.
|
2006-04-10 09:33:06 +00:00
|
|
|
*/
|
|
|
|
if (leading >= trailing) {
|
2008-01-27 01:42:49 +00:00
|
|
|
remove_first_line(&preimage);
|
|
|
|
remove_first_line(&postimage);
|
2006-04-10 09:33:06 +00:00
|
|
|
pos--;
|
|
|
|
leading--;
|
|
|
|
}
|
|
|
|
if (trailing > leading) {
|
2008-01-27 01:42:49 +00:00
|
|
|
remove_last_line(&preimage);
|
|
|
|
remove_last_line(&postimage);
|
2006-04-10 09:33:06 +00:00
|
|
|
trailing--;
|
2005-06-05 19:16:32 +00:00
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
if (applied_pos >= 0) {
|
apply --whitespace=warn/error: diagnose blank at EOF
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 23:02:32 +00:00
|
|
|
if (new_blank_lines_at_end &&
|
2010-03-06 14:30:42 +00:00
|
|
|
preimage.nr + applied_pos >= img->nr &&
|
apply --whitespace=warn/error: diagnose blank at EOF
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 23:02:32 +00:00
|
|
|
(ws_rule & WS_BLANK_AT_EOF) &&
|
2016-05-24 08:11:17 +00:00
|
|
|
state->ws_error_action != nowarn_ws_error) {
|
2016-05-24 08:11:06 +00:00
|
|
|
record_ws_error(state, WS_BLANK_AT_EOF, "+", 1,
|
2011-09-26 20:30:30 +00:00
|
|
|
found_new_blank_lines_at_end);
|
2016-05-24 08:11:17 +00:00
|
|
|
if (state->ws_error_action == correct_ws_error) {
|
apply --whitespace=warn/error: diagnose blank at EOF
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 23:02:32 +00:00
|
|
|
while (new_blank_lines_at_end--)
|
|
|
|
remove_last_line(&postimage);
|
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
/*
|
apply --whitespace=warn/error: diagnose blank at EOF
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03 23:02:32 +00:00
|
|
|
* We would want to prevent write_out_results()
|
|
|
|
* from taking place in apply_patch() that follows
|
|
|
|
* the callchain led us here, which is:
|
|
|
|
* apply_patch->check_patch_list->check_patch->
|
|
|
|
* apply_data->apply_fragments->apply_one_fragment
|
2008-01-27 01:42:49 +00:00
|
|
|
*/
|
2016-05-24 08:11:17 +00:00
|
|
|
if (state->ws_error_action == die_on_ws_error)
|
2016-05-24 08:11:05 +00:00
|
|
|
state->apply = 0;
|
2008-01-27 01:42:49 +00:00
|
|
|
}
|
2007-02-22 19:11:21 +00:00
|
|
|
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely && applied_pos != pos) {
|
2011-03-04 22:43:45 +00:00
|
|
|
int offset = applied_pos - pos;
|
2016-05-24 08:10:50 +00:00
|
|
|
if (state->apply_in_reverse)
|
2011-03-04 22:43:45 +00:00
|
|
|
offset = 0 - offset;
|
2012-04-23 12:30:27 +00:00
|
|
|
fprintf_ln(stderr,
|
|
|
|
Q_("Hunk #%d succeeded at %d (offset %d line).",
|
|
|
|
"Hunk #%d succeeded at %d (offset %d lines).",
|
|
|
|
offset),
|
|
|
|
nth_fragment, applied_pos + 1, offset);
|
2011-03-04 22:43:45 +00:00
|
|
|
}
|
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
/*
|
|
|
|
* Warn if it was necessary to reduce the number
|
|
|
|
* of context lines.
|
|
|
|
*/
|
|
|
|
if ((leading != frag->leading) ||
|
|
|
|
(trailing != frag->trailing))
|
2012-04-23 12:30:27 +00:00
|
|
|
fprintf_ln(stderr, _("Context reduced to (%ld/%ld)"
|
|
|
|
" to apply fragment at %d"),
|
|
|
|
leading, trailing, applied_pos+1);
|
2016-05-24 08:10:54 +00:00
|
|
|
update_image(state, img, applied_pos, &preimage, &postimage);
|
2008-01-27 01:42:49 +00:00
|
|
|
} else {
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely)
|
2012-04-23 12:30:27 +00:00
|
|
|
error(_("while searching for:\n%.*s"),
|
2008-01-30 21:12:25 +00:00
|
|
|
(int)(old - oldlines), oldlines);
|
2008-01-27 01:42:49 +00:00
|
|
|
}
|
2007-02-22 19:11:21 +00:00
|
|
|
|
2015-03-21 00:28:02 +00:00
|
|
|
out:
|
2008-01-30 21:12:25 +00:00
|
|
|
free(oldlines);
|
2010-04-02 23:37:23 +00:00
|
|
|
strbuf_release(&newlines);
|
2008-01-27 01:42:49 +00:00
|
|
|
free(preimage.line_allocated);
|
|
|
|
free(postimage.line_allocated);
|
|
|
|
|
|
|
|
return (applied_pos < 0);
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:50 +00:00
|
|
|
static int apply_binary_fragment(struct apply_state *state,
|
|
|
|
struct image *img,
|
|
|
|
struct patch *patch)
|
2006-05-05 09:41:53 +00:00
|
|
|
{
|
|
|
|
struct fragment *fragment = patch->fragments;
|
2007-09-16 16:54:42 +00:00
|
|
|
unsigned long len;
|
|
|
|
void *dst;
|
2006-05-05 09:41:53 +00:00
|
|
|
|
apply: don't segfault on binary files with missing data
Usually when applying a binary diff generated without
--binary, it will be rejected early, as we don't even have
the full sha1 of the pre- and post-images.
However, if the diff is generated with --full-index (but not
--binary), then we will actually try to apply it. If we have
the postimage blob, then we can take a shortcut and never
even look at the binary diff at all (e.g., this can happen
when rebasing changes within a repository).
If we don't have the postimage blob, though, we try to look
at the actual fragments, of which there are none, and get a
segfault. This patch checks explicitly for that case and
complains to the user instead of segfaulting. We need to
keep the check at a low level so that the "shortcut" case
above continues to work.
We also add a test that demonstrates the segfault. While
we're at it, let's also explicitly test the shortcut case.
Reported-by: Rafaël Carré <rafael.carre@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-18 18:39:17 +00:00
|
|
|
if (!fragment)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("missing binary patch data for '%s'"),
|
apply: don't segfault on binary files with missing data
Usually when applying a binary diff generated without
--binary, it will be rejected early, as we don't even have
the full sha1 of the pre- and post-images.
However, if the diff is generated with --full-index (but not
--binary), then we will actually try to apply it. If we have
the postimage blob, then we can take a shortcut and never
even look at the binary diff at all (e.g., this can happen
when rebasing changes within a repository).
If we don't have the postimage blob, though, we try to look
at the actual fragments, of which there are none, and get a
segfault. This patch checks explicitly for that case and
complains to the user instead of segfaulting. We need to
keep the check at a low level so that the "shortcut" case
above continues to work.
We also add a test that demonstrates the segfault. While
we're at it, let's also explicitly test the shortcut case.
Reported-by: Rafaël Carré <rafael.carre@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-18 18:39:17 +00:00
|
|
|
patch->new_name ?
|
|
|
|
patch->new_name :
|
|
|
|
patch->old_name);
|
|
|
|
|
2006-08-15 09:23:06 +00:00
|
|
|
/* Binary patch is irreversible without the optional second hunk */
|
2016-05-24 08:10:50 +00:00
|
|
|
if (state->apply_in_reverse) {
|
2006-08-15 09:23:06 +00:00
|
|
|
if (!fragment->next)
|
|
|
|
return error("cannot reverse-apply a binary patch "
|
|
|
|
"without the reverse hunk to '%s'",
|
|
|
|
patch->new_name
|
|
|
|
? patch->new_name : patch->old_name);
|
2006-08-16 23:07:20 +00:00
|
|
|
fragment = fragment->next;
|
2006-08-15 09:23:06 +00:00
|
|
|
}
|
|
|
|
switch (fragment->binary_patch_method) {
|
2006-05-05 09:41:53 +00:00
|
|
|
case BINARY_DELTA_DEFLATED:
|
2008-01-27 01:42:49 +00:00
|
|
|
dst = patch_delta(img->buf, img->len, fragment->patch,
|
2007-09-16 16:54:42 +00:00
|
|
|
fragment->size, &len);
|
|
|
|
if (!dst)
|
|
|
|
return -1;
|
2008-01-27 01:42:49 +00:00
|
|
|
clear_image(img);
|
|
|
|
img->buf = dst;
|
|
|
|
img->len = len;
|
2007-09-16 16:54:42 +00:00
|
|
|
return 0;
|
2006-05-05 09:41:53 +00:00
|
|
|
case BINARY_LITERAL_DEFLATED:
|
2008-01-27 01:42:49 +00:00
|
|
|
clear_image(img);
|
|
|
|
img->len = fragment->size;
|
2014-07-19 15:35:34 +00:00
|
|
|
img->buf = xmemdupz(fragment->patch, img->len);
|
2007-09-16 16:54:42 +00:00
|
|
|
return 0;
|
2006-05-05 09:41:53 +00:00
|
|
|
}
|
2007-09-16 16:54:42 +00:00
|
|
|
return -1;
|
2006-05-05 09:41:53 +00:00
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* Replace "img" with the result of applying the binary patch.
|
|
|
|
* The binary patch data itself in patch->fragment is still kept
|
|
|
|
* but the preimage prepared by the caller in "img" is freed here
|
|
|
|
* or in the helper function apply_binary_fragment() this calls.
|
|
|
|
*/
|
2016-05-24 08:10:50 +00:00
|
|
|
static int apply_binary(struct apply_state *state,
|
|
|
|
struct image *img,
|
|
|
|
struct patch *patch)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
2005-11-15 01:37:05 +00:00
|
|
|
const char *name = patch->old_name ? patch->old_name : patch->new_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
|
|
|
unsigned char sha1[20];
|
2005-11-15 01:37:05 +00:00
|
|
|
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* For safety, we require patch index line to contain
|
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
|
|
|
* full 40-byte textual SHA1 for old and new, at least for now.
|
|
|
|
*/
|
|
|
|
if (strlen(patch->old_sha1_prefix) != 40 ||
|
|
|
|
strlen(patch->new_sha1_prefix) != 40 ||
|
|
|
|
get_sha1_hex(patch->old_sha1_prefix, sha1) ||
|
|
|
|
get_sha1_hex(patch->new_sha1_prefix, sha1))
|
|
|
|
return error("cannot apply binary patch to '%s' "
|
|
|
|
"without full index line", name);
|
2005-11-15 01:37:05 +00:00
|
|
|
|
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 (patch->old_name) {
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* See if the old one matches what the patch
|
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
|
|
|
* applies to.
|
2005-11-15 01:37:05 +00:00
|
|
|
*/
|
2008-01-27 01:42:49 +00:00
|
|
|
hash_sha1_file(img->buf, img->len, blob_type, sha1);
|
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 (strcmp(sha1_to_hex(sha1), patch->old_sha1_prefix))
|
|
|
|
return error("the patch applies to '%s' (%s), "
|
|
|
|
"which does not match the "
|
|
|
|
"current contents.",
|
|
|
|
name, sha1_to_hex(sha1));
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* Otherwise, the old one must be empty. */
|
2008-01-27 01:42:49 +00:00
|
|
|
if (img->len)
|
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
|
|
|
return error("the patch applies to an empty "
|
|
|
|
"'%s' but it is not empty", name);
|
|
|
|
}
|
2005-11-15 01:37:05 +00:00
|
|
|
|
2006-05-05 09:41:53 +00:00
|
|
|
get_sha1_hex(patch->new_sha1_prefix, sha1);
|
2006-08-15 20:37:19 +00:00
|
|
|
if (is_null_sha1(sha1)) {
|
2008-01-27 01:42:49 +00:00
|
|
|
clear_image(img);
|
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
|
|
|
return 0; /* deletion patch */
|
2006-05-05 09:41:53 +00:00
|
|
|
}
|
2005-11-15 01:37:05 +00:00
|
|
|
|
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 (has_sha1_file(sha1)) {
|
2006-05-05 09:41:53 +00:00
|
|
|
/* We already have the postimage */
|
2007-02-26 19:55:59 +00:00
|
|
|
enum object_type type;
|
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
|
|
|
unsigned long size;
|
2007-09-16 16:54:42 +00:00
|
|
|
char *result;
|
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
|
|
|
|
2007-09-16 16:54:42 +00:00
|
|
|
result = read_sha1_file(sha1, &type, &size);
|
|
|
|
if (!result)
|
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
|
|
|
return error("the necessary postimage %s for "
|
|
|
|
"'%s' cannot be read",
|
|
|
|
patch->new_sha1_prefix, name);
|
2008-01-27 01:42:49 +00:00
|
|
|
clear_image(img);
|
|
|
|
img->buf = result;
|
|
|
|
img->len = size;
|
2007-09-16 16:54:42 +00:00
|
|
|
} else {
|
2007-11-23 10:37:03 +00:00
|
|
|
/*
|
|
|
|
* We have verified buf matches the preimage;
|
2006-05-05 09:41:53 +00:00
|
|
|
* apply the patch data to it, which is stored
|
|
|
|
* in the patch->fragments->{patch,size}.
|
2005-11-15 01:37:05 +00:00
|
|
|
*/
|
2016-05-24 08:10:50 +00:00
|
|
|
if (apply_binary_fragment(state, img, patch))
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("binary patch does not apply to '%s'"),
|
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
|
|
|
name);
|
2005-11-15 01:37:05 +00:00
|
|
|
|
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
|
|
|
/* verify that the result matches */
|
2008-01-27 01:42:49 +00:00
|
|
|
hash_sha1_file(img->buf, img->len, blob_type, sha1);
|
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 (strcmp(sha1_to_hex(sha1), patch->new_sha1_prefix))
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("binary patch to '%s' creates incorrect result (expecting %s, got %s)"),
|
2007-09-16 16:54:42 +00:00
|
|
|
name, patch->new_sha1_prefix, sha1_to_hex(sha1));
|
2005-11-15 01:37:05 +00:00
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
|
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
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:47 +00:00
|
|
|
static int apply_fragments(struct apply_state *state, struct image *img, struct patch *patch)
|
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 fragment *frag = patch->fragments;
|
|
|
|
const char *name = patch->old_name ? patch->old_name : patch->new_name;
|
2007-12-06 08:14:14 +00:00
|
|
|
unsigned ws_rule = patch->ws_rule;
|
|
|
|
unsigned inaccurate_eof = patch->inaccurate_eof;
|
2011-03-04 22:43:45 +00:00
|
|
|
int nth = 0;
|
binary patch.
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04 23:51:44 +00:00
|
|
|
|
|
|
|
if (patch->is_binary)
|
2016-05-24 08:10:50 +00:00
|
|
|
return apply_binary(state, img, patch);
|
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
|
|
|
|
2005-06-05 18:03:13 +00:00
|
|
|
while (frag) {
|
2011-03-04 22:43:45 +00:00
|
|
|
nth++;
|
2016-05-24 08:10:47 +00:00
|
|
|
if (apply_one_fragment(state, img, frag, inaccurate_eof, ws_rule, nth)) {
|
2012-04-23 12:30:27 +00:00
|
|
|
error(_("patch failed: %s:%ld"), name, frag->oldpos);
|
2016-05-24 08:10:51 +00:00
|
|
|
if (!state->apply_with_reject)
|
2006-08-17 00:55:29 +00:00
|
|
|
return -1;
|
|
|
|
frag->rejected = 1;
|
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
frag = frag->next;
|
|
|
|
}
|
2005-06-05 19:43:56 +00:00
|
|
|
return 0;
|
2005-06-05 18:03:13 +00:00
|
|
|
}
|
|
|
|
|
2012-05-08 22:11:02 +00:00
|
|
|
static int read_blob_object(struct strbuf *buf, const unsigned char *sha1, unsigned mode)
|
2007-08-15 17:22:09 +00:00
|
|
|
{
|
2012-05-08 22:11:02 +00:00
|
|
|
if (S_ISGITLINK(mode)) {
|
2007-09-16 16:54:42 +00:00
|
|
|
strbuf_grow(buf, 100);
|
2012-05-08 22:11:02 +00:00
|
|
|
strbuf_addf(buf, "Subproject commit %s\n", sha1_to_hex(sha1));
|
2007-08-15 17:22:09 +00:00
|
|
|
} else {
|
|
|
|
enum object_type type;
|
2007-09-16 16:54:42 +00:00
|
|
|
unsigned long sz;
|
|
|
|
char *result;
|
|
|
|
|
2012-05-08 22:11:02 +00:00
|
|
|
result = read_sha1_file(sha1, &type, &sz);
|
2007-09-16 16:54:42 +00:00
|
|
|
if (!result)
|
2007-08-15 17:22:09 +00:00
|
|
|
return -1;
|
2007-09-16 16:54:42 +00:00
|
|
|
/* XXX read_sha1_file NUL-terminates */
|
|
|
|
strbuf_attach(buf, result, sz, sz + 1);
|
2007-08-15 17:22:09 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
static int read_file_or_gitlink(const struct cache_entry *ce, struct strbuf *buf)
|
2012-05-08 22:11:02 +00:00
|
|
|
{
|
|
|
|
if (!ce)
|
|
|
|
return 0;
|
|
|
|
return read_blob_object(buf, ce->sha1, ce->ce_mode);
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
static struct patch *in_fn_table(struct apply_state *state, const char *name)
|
2008-06-27 18:39:12 +00:00
|
|
|
{
|
2008-07-21 18:03:49 +00:00
|
|
|
struct string_list_item *item;
|
2008-06-27 18:39:12 +00:00
|
|
|
|
|
|
|
if (name == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
item = string_list_lookup(&state->fn_table, name);
|
2008-06-27 18:39:12 +00:00
|
|
|
if (item != NULL)
|
|
|
|
return (struct patch *)item->util;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-04-11 19:31:00 +00:00
|
|
|
/*
|
|
|
|
* item->util in the filename table records the status of the path.
|
|
|
|
* Usually it points at a patch (whose result records the contents
|
|
|
|
* of it after applying it), but it could be PATH_WAS_DELETED for a
|
2012-05-16 20:21:39 +00:00
|
|
|
* path that a previously applied patch has already removed, or
|
|
|
|
* PATH_TO_BE_DELETED for a path that a later patch would remove.
|
|
|
|
*
|
|
|
|
* The latter is needed to deal with a case where two paths A and B
|
|
|
|
* are swapped by first renaming A to B and then renaming B to A;
|
2013-04-11 22:36:10 +00:00
|
|
|
* moving A to B should not be prevented due to presence of B as we
|
2012-05-16 20:21:39 +00:00
|
|
|
* will remove it in a later patch.
|
2009-04-11 19:31:00 +00:00
|
|
|
*/
|
2012-05-16 20:21:39 +00:00
|
|
|
#define PATH_TO_BE_DELETED ((struct patch *) -2)
|
2009-04-11 19:31:00 +00:00
|
|
|
#define PATH_WAS_DELETED ((struct patch *) -1)
|
|
|
|
|
|
|
|
static int to_be_deleted(struct patch *patch)
|
|
|
|
{
|
|
|
|
return patch == PATH_TO_BE_DELETED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int was_deleted(struct patch *patch)
|
|
|
|
{
|
|
|
|
return patch == PATH_WAS_DELETED;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
static void add_to_fn_table(struct apply_state *state, struct patch *patch)
|
2008-06-27 18:39:12 +00:00
|
|
|
{
|
2008-07-21 18:03:49 +00:00
|
|
|
struct string_list_item *item;
|
2008-06-27 18:39:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Always add new_name unless patch is a deletion
|
|
|
|
* This should cover the cases for normal diffs,
|
|
|
|
* file creations and copies
|
|
|
|
*/
|
|
|
|
if (patch->new_name != NULL) {
|
2016-05-24 08:11:21 +00:00
|
|
|
item = string_list_insert(&state->fn_table, patch->new_name);
|
2008-06-27 18:39:12 +00:00
|
|
|
item->util = patch;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* store a failure on rename/deletion cases because
|
|
|
|
* later chunks shouldn't patch old names
|
|
|
|
*/
|
|
|
|
if ((patch->new_name == NULL) || (patch->is_rename)) {
|
2016-05-24 08:11:21 +00:00
|
|
|
item = string_list_insert(&state->fn_table, patch->old_name);
|
2009-04-11 19:31:00 +00:00
|
|
|
item->util = PATH_WAS_DELETED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
static void prepare_fn_table(struct apply_state *state, struct patch *patch)
|
2009-04-11 19:31:00 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* store information about incoming file deletion
|
|
|
|
*/
|
|
|
|
while (patch) {
|
|
|
|
if ((patch->new_name == NULL) || (patch->is_rename)) {
|
|
|
|
struct string_list_item *item;
|
2016-05-24 08:11:21 +00:00
|
|
|
item = string_list_insert(&state->fn_table, patch->old_name);
|
2009-04-11 19:31:00 +00:00
|
|
|
item->util = PATH_TO_BE_DELETED;
|
|
|
|
}
|
|
|
|
patch = patch->next;
|
2008-06-27 18:39:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-13 12:19:34 +00:00
|
|
|
static int checkout_target(struct index_state *istate,
|
|
|
|
struct cache_entry *ce, struct stat *st)
|
2012-06-13 05:47:12 +00:00
|
|
|
{
|
|
|
|
struct checkout costate;
|
|
|
|
|
|
|
|
memset(&costate, 0, sizeof(costate));
|
|
|
|
costate.base_dir = "";
|
|
|
|
costate.refresh_cache = 1;
|
2014-06-13 12:19:34 +00:00
|
|
|
costate.istate = istate;
|
2012-06-13 05:47:12 +00:00
|
|
|
if (checkout_entry(ce, &costate, NULL) || lstat(ce->name, st))
|
|
|
|
return error(_("cannot checkout %s"), ce->name);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
static struct patch *previous_patch(struct apply_state *state,
|
|
|
|
struct patch *patch,
|
|
|
|
int *gone)
|
2012-05-16 21:03:52 +00:00
|
|
|
{
|
|
|
|
struct patch *previous;
|
|
|
|
|
|
|
|
*gone = 0;
|
|
|
|
if (patch->is_copy || patch->is_rename)
|
|
|
|
return NULL; /* "git" patches do not depend on the order */
|
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
previous = in_fn_table(state, patch->old_name);
|
2012-05-16 21:03:52 +00:00
|
|
|
if (!previous)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (to_be_deleted(previous))
|
|
|
|
return NULL; /* the deletion hasn't happened yet */
|
|
|
|
|
|
|
|
if (was_deleted(previous))
|
|
|
|
*gone = 1;
|
|
|
|
|
|
|
|
return previous;
|
|
|
|
}
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
static int verify_index_match(const struct cache_entry *ce, struct stat *st)
|
2012-06-13 04:16:02 +00:00
|
|
|
{
|
|
|
|
if (S_ISGITLINK(ce->ce_mode)) {
|
|
|
|
if (!S_ISDIR(st->st_mode))
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return ce_match_stat(ce, st, CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE);
|
|
|
|
}
|
|
|
|
|
2012-06-12 22:23:54 +00:00
|
|
|
#define SUBMODULE_PATCH_WITHOUT_INDEX 1
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
static int load_patch_target(struct apply_state *state,
|
|
|
|
struct strbuf *buf,
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
const struct cache_entry *ce,
|
2012-06-12 22:23:54 +00:00
|
|
|
struct stat *st,
|
|
|
|
const char *name,
|
|
|
|
unsigned expected_mode)
|
|
|
|
{
|
2016-05-24 08:10:55 +00:00
|
|
|
if (state->cached || state->check_index) {
|
2012-06-12 22:23:54 +00:00
|
|
|
if (read_file_or_gitlink(ce, buf))
|
2016-06-17 20:21:20 +00:00
|
|
|
return error(_("failed to read %s"), name);
|
2012-06-12 22:23:54 +00:00
|
|
|
} else if (name) {
|
|
|
|
if (S_ISGITLINK(expected_mode)) {
|
|
|
|
if (ce)
|
|
|
|
return read_file_or_gitlink(ce, buf);
|
|
|
|
else
|
|
|
|
return SUBMODULE_PATCH_WITHOUT_INDEX;
|
2015-01-30 23:34:13 +00:00
|
|
|
} else if (has_symlink_leading_path(name, strlen(name))) {
|
|
|
|
return error(_("reading from '%s' beyond a symbolic link"), name);
|
2012-06-12 22:23:54 +00:00
|
|
|
} else {
|
|
|
|
if (read_old_data(st, name, buf))
|
2016-06-17 20:21:20 +00:00
|
|
|
return error(_("failed to read %s"), name);
|
2012-06-12 22:23:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-16 21:03:52 +00:00
|
|
|
/*
|
|
|
|
* We are about to apply "patch"; populate the "image" with the
|
|
|
|
* current version we have, from the working tree or from the index,
|
|
|
|
* depending on the situation e.g. --cached/--index. If we are
|
|
|
|
* applying a non-git patch that incrementally updates the tree,
|
|
|
|
* we read from the result of a previous diff.
|
|
|
|
*/
|
2016-05-24 08:10:49 +00:00
|
|
|
static int load_preimage(struct apply_state *state,
|
|
|
|
struct image *image,
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
struct patch *patch, struct stat *st,
|
|
|
|
const struct cache_entry *ce)
|
2005-06-05 18:03:13 +00:00
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2008-01-27 01:42:49 +00:00
|
|
|
size_t len;
|
|
|
|
char *img;
|
2012-05-16 21:03:52 +00:00
|
|
|
struct patch *previous;
|
|
|
|
int status;
|
2005-06-05 18:03:13 +00:00
|
|
|
|
2016-05-24 08:11:21 +00:00
|
|
|
previous = previous_patch(state, patch, &status);
|
2012-05-16 21:03:52 +00:00
|
|
|
if (status)
|
|
|
|
return error(_("path %s has been renamed/deleted"),
|
|
|
|
patch->old_name);
|
|
|
|
if (previous) {
|
2012-04-11 21:43:48 +00:00
|
|
|
/* We have a patched copy in memory; use that. */
|
2012-05-16 21:03:52 +00:00
|
|
|
strbuf_add(&buf, previous->result, previous->resultsize);
|
2012-06-12 22:23:54 +00:00
|
|
|
} else {
|
2016-05-24 08:10:49 +00:00
|
|
|
status = load_patch_target(state, &buf, ce, st,
|
2012-06-12 22:23:54 +00:00
|
|
|
patch->old_name, patch->old_mode);
|
|
|
|
if (status < 0)
|
|
|
|
return status;
|
|
|
|
else if (status == SUBMODULE_PATCH_WITHOUT_INDEX) {
|
|
|
|
/*
|
|
|
|
* There is no way to apply subproject
|
|
|
|
* patch without looking at the index.
|
|
|
|
* NEEDSWORK: shouldn't this be flagged
|
|
|
|
* as an error???
|
|
|
|
*/
|
|
|
|
free_fragment_list(patch->fragments);
|
|
|
|
patch->fragments = NULL;
|
|
|
|
} else if (status) {
|
2016-06-17 20:21:20 +00:00
|
|
|
return error(_("failed to read %s"), patch->old_name);
|
2006-05-15 22:15:47 +00:00
|
|
|
}
|
|
|
|
}
|
2005-06-05 19:16:32 +00:00
|
|
|
|
2008-01-27 01:42:49 +00:00
|
|
|
img = strbuf_detach(&buf, &len);
|
2012-05-08 20:35:21 +00:00
|
|
|
prepare_image(image, img, len, !patch->is_binary);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
|
2012-06-08 16:54:10 +00:00
|
|
|
static int three_way_merge(struct image *image,
|
|
|
|
char *path,
|
|
|
|
const unsigned char *base,
|
|
|
|
const unsigned char *ours,
|
|
|
|
const unsigned char *theirs)
|
|
|
|
{
|
2012-05-09 23:10:51 +00:00
|
|
|
mmfile_t base_file, our_file, their_file;
|
|
|
|
mmbuffer_t result = { NULL };
|
|
|
|
int status;
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2012-05-09 23:10:51 +00:00
|
|
|
read_mmblob(&base_file, base);
|
|
|
|
read_mmblob(&our_file, ours);
|
|
|
|
read_mmblob(&their_file, theirs);
|
|
|
|
status = ll_merge(&result, path,
|
|
|
|
&base_file, "base",
|
|
|
|
&our_file, "ours",
|
|
|
|
&their_file, "theirs", NULL);
|
|
|
|
free(base_file.ptr);
|
|
|
|
free(our_file.ptr);
|
|
|
|
free(their_file.ptr);
|
|
|
|
if (status < 0 || !result.ptr) {
|
|
|
|
free(result.ptr);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
clear_image(image);
|
|
|
|
image->buf = result.ptr;
|
|
|
|
image->len = result.size;
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2012-05-09 23:10:51 +00:00
|
|
|
return status;
|
2012-06-08 16:54:10 +00:00
|
|
|
}
|
|
|
|
|
2012-06-07 22:04:11 +00:00
|
|
|
/*
|
|
|
|
* When directly falling back to add/add three-way merge, we read from
|
|
|
|
* the current contents of the new_name. In no cases other than that
|
|
|
|
* this function will be called.
|
|
|
|
*/
|
2016-05-24 08:10:49 +00:00
|
|
|
static int load_current(struct apply_state *state,
|
|
|
|
struct image *image,
|
|
|
|
struct patch *patch)
|
2012-06-07 22:04:11 +00:00
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
int status, pos;
|
|
|
|
size_t len;
|
|
|
|
char *img;
|
|
|
|
struct stat st;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
char *name = patch->new_name;
|
|
|
|
unsigned mode = patch->new_mode;
|
|
|
|
|
|
|
|
if (!patch->is_new)
|
|
|
|
die("BUG: patch to %s is not a creation", patch->old_name);
|
|
|
|
|
|
|
|
pos = cache_name_pos(name, strlen(name));
|
|
|
|
if (pos < 0)
|
|
|
|
return error(_("%s: does not exist in index"), name);
|
|
|
|
ce = active_cache[pos];
|
|
|
|
if (lstat(name, &st)) {
|
|
|
|
if (errno != ENOENT)
|
|
|
|
return error(_("%s: %s"), name, strerror(errno));
|
2014-06-13 12:19:34 +00:00
|
|
|
if (checkout_target(&the_index, ce, &st))
|
2012-06-07 22:04:11 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (verify_index_match(ce, &st))
|
|
|
|
return error(_("%s: does not match index"), name);
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
status = load_patch_target(state, &buf, ce, &st, name, mode);
|
2012-06-07 22:04:11 +00:00
|
|
|
if (status < 0)
|
|
|
|
return status;
|
|
|
|
else if (status)
|
|
|
|
return -1;
|
|
|
|
img = strbuf_detach(&buf, &len);
|
|
|
|
prepare_image(image, img, len, !patch->is_binary);
|
2005-06-05 18:03:13 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:47 +00:00
|
|
|
static int try_threeway(struct apply_state *state,
|
|
|
|
struct image *image,
|
|
|
|
struct patch *patch,
|
|
|
|
struct stat *st,
|
|
|
|
const struct cache_entry *ce)
|
apply: do not get confused by symlinks in the middle
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-12 05:26:08 +00:00
|
|
|
{
|
2012-06-08 16:54:10 +00:00
|
|
|
unsigned char pre_sha1[20], post_sha1[20], our_sha1[20];
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
size_t len;
|
2012-05-09 23:10:51 +00:00
|
|
|
int status;
|
2012-06-08 16:54:10 +00:00
|
|
|
char *img;
|
|
|
|
struct image tmp_image;
|
|
|
|
|
|
|
|
/* No point falling back to 3-way merge in these cases */
|
2012-06-07 22:04:11 +00:00
|
|
|
if (patch->is_delete ||
|
2012-06-08 16:54:10 +00:00
|
|
|
S_ISGITLINK(patch->old_mode) || S_ISGITLINK(patch->new_mode))
|
|
|
|
return -1;
|
apply: do not get confused by symlinks in the middle
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-12 05:26:08 +00:00
|
|
|
|
2012-06-08 16:54:10 +00:00
|
|
|
/* Preimage the patch was prepared for */
|
2012-06-07 22:04:11 +00:00
|
|
|
if (patch->is_new)
|
|
|
|
write_sha1_file("", 0, blob_type, pre_sha1);
|
|
|
|
else if (get_sha1(patch->old_sha1_prefix, pre_sha1) ||
|
|
|
|
read_blob_object(&buf, pre_sha1, patch->old_mode))
|
2012-06-08 16:54:10 +00:00
|
|
|
return error("repository lacks the necessary blob to fall back on 3-way merge.");
|
2012-05-09 23:10:51 +00:00
|
|
|
|
|
|
|
fprintf(stderr, "Falling back to three-way merge...\n");
|
|
|
|
|
2012-06-08 16:54:10 +00:00
|
|
|
img = strbuf_detach(&buf, &len);
|
|
|
|
prepare_image(&tmp_image, img, len, 1);
|
|
|
|
/* Apply the patch to get the post image */
|
2016-05-24 08:10:47 +00:00
|
|
|
if (apply_fragments(state, &tmp_image, patch) < 0) {
|
2012-06-08 16:54:10 +00:00
|
|
|
clear_image(&tmp_image);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
/* post_sha1[] is theirs */
|
|
|
|
write_sha1_file(tmp_image.buf, tmp_image.len, blob_type, post_sha1);
|
|
|
|
clear_image(&tmp_image);
|
|
|
|
|
|
|
|
/* our_sha1[] is ours */
|
2012-06-07 22:04:11 +00:00
|
|
|
if (patch->is_new) {
|
2016-05-24 08:10:49 +00:00
|
|
|
if (load_current(state, &tmp_image, patch))
|
2012-06-07 22:04:11 +00:00
|
|
|
return error("cannot read the current contents of '%s'",
|
|
|
|
patch->new_name);
|
|
|
|
} else {
|
2016-05-24 08:10:49 +00:00
|
|
|
if (load_preimage(state, &tmp_image, patch, st, ce))
|
2012-06-07 22:04:11 +00:00
|
|
|
return error("cannot read the current contents of '%s'",
|
|
|
|
patch->old_name);
|
|
|
|
}
|
2012-06-08 16:54:10 +00:00
|
|
|
write_sha1_file(tmp_image.buf, tmp_image.len, blob_type, our_sha1);
|
|
|
|
clear_image(&tmp_image);
|
|
|
|
|
|
|
|
/* in-core three-way merge between post and our using pre as base */
|
2012-05-09 23:10:51 +00:00
|
|
|
status = three_way_merge(image, patch->new_name,
|
|
|
|
pre_sha1, our_sha1, post_sha1);
|
|
|
|
if (status < 0) {
|
|
|
|
fprintf(stderr, "Failed to fall back on three-way merge...\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (status) {
|
|
|
|
patch->conflicted_threeway = 1;
|
2012-05-09 23:50:58 +00:00
|
|
|
if (patch->is_new)
|
2015-03-13 23:39:36 +00:00
|
|
|
oidclr(&patch->threeway_stage[0]);
|
2012-05-09 23:50:58 +00:00
|
|
|
else
|
2015-03-13 23:39:36 +00:00
|
|
|
hashcpy(patch->threeway_stage[0].hash, pre_sha1);
|
|
|
|
hashcpy(patch->threeway_stage[1].hash, our_sha1);
|
|
|
|
hashcpy(patch->threeway_stage[2].hash, post_sha1);
|
2012-05-09 23:10:51 +00:00
|
|
|
fprintf(stderr, "Applied patch to '%s' with conflicts.\n", patch->new_name);
|
|
|
|
} else {
|
|
|
|
fprintf(stderr, "Applied patch to '%s' cleanly.\n", patch->new_name);
|
apply: do not get confused by symlinks in the middle
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-12 05:26:08 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:47 +00:00
|
|
|
static int apply_data(struct apply_state *state, struct patch *patch,
|
|
|
|
struct stat *st, const struct cache_entry *ce)
|
2007-08-15 17:22:09 +00:00
|
|
|
{
|
2012-05-08 20:35:21 +00:00
|
|
|
struct image image;
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
if (load_preimage(state, &image, patch, st, ce) < 0)
|
2012-05-08 20:35:21 +00:00
|
|
|
return -1;
|
2008-01-27 01:42:49 +00:00
|
|
|
|
2012-06-07 22:04:11 +00:00
|
|
|
if (patch->direct_to_threeway ||
|
2016-05-24 08:10:47 +00:00
|
|
|
apply_fragments(state, &image, patch) < 0) {
|
2012-05-08 20:21:53 +00:00
|
|
|
/* Note: with --reject, apply_fragments() returns 0 */
|
2016-05-24 08:10:59 +00:00
|
|
|
if (!state->threeway || try_threeway(state, &image, patch, st, ce) < 0)
|
2007-08-15 17:22:09 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2008-01-27 01:42:49 +00:00
|
|
|
patch->result = image.buf;
|
|
|
|
patch->resultsize = image.len;
|
2016-05-24 08:11:21 +00:00
|
|
|
add_to_fn_table(state, patch);
|
2008-01-27 01:42:49 +00:00
|
|
|
free(image.line_allocated);
|
2005-06-05 21:05:43 +00:00
|
|
|
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (0 < patch->is_delete && patch->resultsize)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("removal patch leaves file contents"));
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2005-06-05 18:03:13 +00:00
|
|
|
return 0;
|
2007-08-15 17:22:09 +00:00
|
|
|
}
|
|
|
|
|
2012-05-16 21:03:52 +00:00
|
|
|
/*
|
|
|
|
* If "patch" that we are looking at modifies or deletes what we have,
|
|
|
|
* we would want it not to lose any local modification we have, either
|
|
|
|
* in the working tree or in the index.
|
|
|
|
*
|
|
|
|
* This also decides if a non-git patch is a creation patch or a
|
|
|
|
* modification to an existing empty file. We do not check the state
|
|
|
|
* of the current tree for a creation patch in this function; the caller
|
|
|
|
* check_patch() separately makes sure (and errors out otherwise) that
|
|
|
|
* the path the patch creates does not exist in the current tree.
|
|
|
|
*/
|
2016-05-24 08:10:49 +00:00
|
|
|
static int check_preimage(struct apply_state *state,
|
|
|
|
struct patch *patch,
|
|
|
|
struct cache_entry **ce,
|
|
|
|
struct stat *st)
|
2005-05-26 19:25:52 +00:00
|
|
|
{
|
|
|
|
const char *old_name = patch->old_name;
|
2012-05-16 21:03:52 +00:00
|
|
|
struct patch *previous = NULL;
|
|
|
|
int stat_ret = 0, status;
|
2008-05-17 08:51:31 +00:00
|
|
|
unsigned st_mode = 0;
|
2007-08-15 17:22:09 +00:00
|
|
|
|
2008-05-17 08:51:31 +00:00
|
|
|
if (!old_name)
|
|
|
|
return 0;
|
2006-05-15 22:15:47 +00:00
|
|
|
|
2008-05-17 08:51:31 +00:00
|
|
|
assert(patch->is_new <= 0);
|
2016-05-24 08:11:21 +00:00
|
|
|
previous = previous_patch(state, patch, &status);
|
2008-07-10 02:58:23 +00:00
|
|
|
|
2012-05-16 21:03:52 +00:00
|
|
|
if (status)
|
|
|
|
return error(_("path %s has been renamed/deleted"), old_name);
|
|
|
|
if (previous) {
|
|
|
|
st_mode = previous->new_mode;
|
2016-05-24 08:10:55 +00:00
|
|
|
} else if (!state->cached) {
|
2008-05-17 08:51:31 +00:00
|
|
|
stat_ret = lstat(old_name, st);
|
|
|
|
if (stat_ret && errno != ENOENT)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: %s"), old_name, strerror(errno));
|
2008-05-17 08:51:31 +00:00
|
|
|
}
|
2008-07-10 02:58:23 +00:00
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
if (state->check_index && !previous) {
|
2008-05-17 08:51:31 +00:00
|
|
|
int pos = cache_name_pos(old_name, strlen(old_name));
|
|
|
|
if (pos < 0) {
|
|
|
|
if (patch->is_new < 0)
|
|
|
|
goto is_new;
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: does not exist in index"), old_name);
|
2008-05-17 08:51:31 +00:00
|
|
|
}
|
|
|
|
*ce = active_cache[pos];
|
|
|
|
if (stat_ret < 0) {
|
2014-06-13 12:19:34 +00:00
|
|
|
if (checkout_target(&the_index, *ce, st))
|
2008-05-17 08:51:31 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2016-05-24 08:10:55 +00:00
|
|
|
if (!state->cached && verify_index_match(*ce, st))
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: does not match index"), old_name);
|
2016-05-24 08:10:55 +00:00
|
|
|
if (state->cached)
|
2008-05-17 08:51:31 +00:00
|
|
|
st_mode = (*ce)->ce_mode;
|
|
|
|
} else if (stat_ret < 0) {
|
2005-06-05 18:03:13 +00:00
|
|
|
if (patch->is_new < 0)
|
2008-05-17 08:51:31 +00:00
|
|
|
goto is_new;
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: %s"), old_name, strerror(errno));
|
2005-05-26 19:25:52 +00:00
|
|
|
}
|
2005-05-26 22:10:02 +00:00
|
|
|
|
2016-05-24 08:10:55 +00:00
|
|
|
if (!state->cached && !previous)
|
2008-05-17 08:51:31 +00:00
|
|
|
st_mode = ce_mode_from_stat(*ce, st->st_mode);
|
|
|
|
|
|
|
|
if (patch->is_new < 0)
|
|
|
|
patch->is_new = 0;
|
|
|
|
if (!patch->old_mode)
|
|
|
|
patch->old_mode = st_mode;
|
|
|
|
if ((st_mode ^ patch->old_mode) & S_IFMT)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: wrong type"), old_name);
|
2008-05-17 08:51:31 +00:00
|
|
|
if (st_mode != patch->old_mode)
|
2012-04-23 12:30:27 +00:00
|
|
|
warning(_("%s has type %o, expected %o"),
|
2008-05-17 08:51:31 +00:00
|
|
|
old_name, st_mode, patch->old_mode);
|
2009-01-26 07:41:26 +00:00
|
|
|
if (!patch->new_mode && !patch->is_delete)
|
2009-01-02 10:55:37 +00:00
|
|
|
patch->new_mode = st_mode;
|
2008-05-17 08:51:31 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
is_new:
|
|
|
|
patch->is_new = 1;
|
|
|
|
patch->is_delete = 0;
|
2012-03-21 22:18:18 +00:00
|
|
|
free(patch->old_name);
|
2008-05-17 08:51:31 +00:00
|
|
|
patch->old_name = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-06-07 21:10:19 +00:00
|
|
|
|
|
|
|
#define EXISTS_IN_INDEX 1
|
|
|
|
#define EXISTS_IN_WORKTREE 2
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
static int check_to_create(struct apply_state *state,
|
|
|
|
const char *new_name,
|
|
|
|
int ok_if_exists)
|
2012-06-07 21:06:47 +00:00
|
|
|
{
|
|
|
|
struct stat nst;
|
2012-06-07 21:10:19 +00:00
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
if (state->check_index &&
|
2012-06-07 21:10:19 +00:00
|
|
|
cache_name_pos(new_name, strlen(new_name)) >= 0 &&
|
|
|
|
!ok_if_exists)
|
|
|
|
return EXISTS_IN_INDEX;
|
2016-05-24 08:10:55 +00:00
|
|
|
if (state->cached)
|
2012-06-07 21:10:19 +00:00
|
|
|
return 0;
|
|
|
|
|
2012-06-07 21:06:47 +00:00
|
|
|
if (!lstat(new_name, &nst)) {
|
|
|
|
if (S_ISDIR(nst.st_mode) || ok_if_exists)
|
|
|
|
return 0;
|
|
|
|
/*
|
|
|
|
* A leading component of new_name might be a symlink
|
|
|
|
* that is going to be removed with this patch, but
|
|
|
|
* still pointing at somewhere that has the path.
|
|
|
|
* In such a case, path "new_name" does not exist as
|
|
|
|
* far as git is concerned.
|
|
|
|
*/
|
|
|
|
if (has_symlink_leading_path(new_name, strlen(new_name)))
|
|
|
|
return 0;
|
|
|
|
|
2012-06-07 21:10:19 +00:00
|
|
|
return EXISTS_IN_WORKTREE;
|
|
|
|
} else if ((errno != ENOENT) && (errno != ENOTDIR)) {
|
2012-06-07 21:06:47 +00:00
|
|
|
return error("%s: %s", new_name, strerror(errno));
|
2012-06-07 21:10:19 +00:00
|
|
|
}
|
2012-06-07 21:06:47 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
static uintptr_t register_symlink_changes(struct apply_state *state,
|
|
|
|
const char *path,
|
|
|
|
uintptr_t what)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
{
|
|
|
|
struct string_list_item *ent;
|
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
ent = string_list_lookup(&state->symlink_changes, path);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
if (!ent) {
|
2016-05-24 08:11:22 +00:00
|
|
|
ent = string_list_insert(&state->symlink_changes, path);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
ent->util = (void *)0;
|
|
|
|
}
|
|
|
|
ent->util = (void *)(what | ((uintptr_t)ent->util));
|
|
|
|
return (uintptr_t)ent->util;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
static uintptr_t check_symlink_changes(struct apply_state *state, const char *path)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
{
|
|
|
|
struct string_list_item *ent;
|
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
ent = string_list_lookup(&state->symlink_changes, path);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
if (!ent)
|
|
|
|
return 0;
|
|
|
|
return (uintptr_t)ent->util;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
static void prepare_symlink_changes(struct apply_state *state, struct patch *patch)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
{
|
|
|
|
for ( ; patch; patch = patch->next) {
|
|
|
|
if ((patch->old_name && S_ISLNK(patch->old_mode)) &&
|
|
|
|
(patch->is_rename || patch->is_delete))
|
|
|
|
/* the symlink at patch->old_name is removed */
|
2016-08-11 08:52:29 +00:00
|
|
|
register_symlink_changes(state, patch->old_name, APPLY_SYMLINK_GOES_AWAY);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
|
|
|
|
if (patch->new_name && S_ISLNK(patch->new_mode))
|
|
|
|
/* the symlink at patch->new_name is created or remains */
|
2016-08-11 08:52:29 +00:00
|
|
|
register_symlink_changes(state, patch->new_name, APPLY_SYMLINK_IN_RESULT);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
static int path_is_beyond_symlink_1(struct apply_state *state, struct strbuf *name)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
{
|
|
|
|
do {
|
|
|
|
unsigned int change;
|
|
|
|
|
|
|
|
while (--name->len && name->buf[name->len] != '/')
|
|
|
|
; /* scan backwards */
|
|
|
|
if (!name->len)
|
|
|
|
break;
|
|
|
|
name->buf[name->len] = '\0';
|
2016-05-24 08:11:22 +00:00
|
|
|
change = check_symlink_changes(state, name->buf);
|
2016-08-11 08:52:29 +00:00
|
|
|
if (change & APPLY_SYMLINK_IN_RESULT)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
return 1;
|
2016-08-11 08:52:29 +00:00
|
|
|
if (change & APPLY_SYMLINK_GOES_AWAY)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
/*
|
|
|
|
* This cannot be "return 0", because we may
|
|
|
|
* see a new one created at a higher level.
|
|
|
|
*/
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* otherwise, check the preimage */
|
2016-05-24 08:10:49 +00:00
|
|
|
if (state->check_index) {
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
|
|
ce = cache_file_exists(name->buf, name->len, ignore_case);
|
|
|
|
if (ce && S_ISLNK(ce->ce_mode))
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
struct stat st;
|
|
|
|
if (!lstat(name->buf, &st) && S_ISLNK(st.st_mode))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
} while (1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
static int path_is_beyond_symlink(struct apply_state *state, const char *name_)
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct strbuf name = STRBUF_INIT;
|
|
|
|
|
|
|
|
assert(*name_ != '\0');
|
|
|
|
strbuf_addstr(&name, name_);
|
2016-05-24 08:10:49 +00:00
|
|
|
ret = path_is_beyond_symlink_1(state, &name);
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
strbuf_release(&name);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:15 +00:00
|
|
|
static int check_unsafe_path(struct patch *patch)
|
2015-01-29 23:35:24 +00:00
|
|
|
{
|
|
|
|
const char *old_name = NULL;
|
|
|
|
const char *new_name = NULL;
|
|
|
|
if (patch->is_delete)
|
|
|
|
old_name = patch->old_name;
|
|
|
|
else if (!patch->is_new && !patch->is_copy)
|
|
|
|
old_name = patch->old_name;
|
|
|
|
if (!patch->is_delete)
|
|
|
|
new_name = patch->new_name;
|
|
|
|
|
|
|
|
if (old_name && !verify_path(old_name))
|
2016-08-08 21:03:15 +00:00
|
|
|
return error(_("invalid path '%s'"), old_name);
|
2015-01-29 23:35:24 +00:00
|
|
|
if (new_name && !verify_path(new_name))
|
2016-08-08 21:03:15 +00:00
|
|
|
return error(_("invalid path '%s'"), new_name);
|
|
|
|
return 0;
|
2015-01-29 23:35:24 +00:00
|
|
|
}
|
|
|
|
|
2012-04-11 21:43:48 +00:00
|
|
|
/*
|
|
|
|
* Check and apply the patch in-core; leave the result in patch->result
|
|
|
|
* for the caller to write it out to the final destination.
|
|
|
|
*/
|
2016-05-24 08:10:47 +00:00
|
|
|
static int check_patch(struct apply_state *state, struct patch *patch)
|
2008-05-17 08:51:31 +00:00
|
|
|
{
|
|
|
|
struct stat st;
|
|
|
|
const char *old_name = patch->old_name;
|
|
|
|
const char *new_name = patch->new_name;
|
|
|
|
const char *name = old_name ? old_name : new_name;
|
|
|
|
struct cache_entry *ce = NULL;
|
2009-04-11 19:31:00 +00:00
|
|
|
struct patch *tpatch;
|
2008-05-17 08:51:31 +00:00
|
|
|
int ok_if_exists;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
patch->rejected = 1; /* we will drop this after we succeed */
|
|
|
|
|
2016-05-24 08:10:49 +00:00
|
|
|
status = check_preimage(state, patch, &ce, &st);
|
2008-05-17 08:51:31 +00:00
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
old_name = patch->old_name;
|
|
|
|
|
2012-05-16 22:31:18 +00:00
|
|
|
/*
|
|
|
|
* A type-change diff is always split into a patch to delete
|
|
|
|
* old, immediately followed by a patch to create new (see
|
|
|
|
* diff.c::run_diff()); in such a case it is Ok that the entry
|
|
|
|
* to be deleted by the previous patch is still in the working
|
|
|
|
* tree and in the index.
|
|
|
|
*
|
|
|
|
* A patch to swap-rename between A and B would first rename A
|
|
|
|
* to B and then rename B to A. While applying the first one,
|
2013-04-11 22:36:10 +00:00
|
|
|
* the presence of B should not stop A from getting renamed to
|
2012-05-16 22:31:18 +00:00
|
|
|
* B; ask to_be_deleted() about the later rename. Removal of
|
|
|
|
* B and rename from A to B is handled the same way by asking
|
|
|
|
* was_deleted().
|
|
|
|
*/
|
2016-05-24 08:11:21 +00:00
|
|
|
if ((tpatch = in_fn_table(state, new_name)) &&
|
2012-05-16 22:31:18 +00:00
|
|
|
(was_deleted(tpatch) || to_be_deleted(tpatch)))
|
2006-07-17 07:10:47 +00:00
|
|
|
ok_if_exists = 1;
|
|
|
|
else
|
|
|
|
ok_if_exists = 0;
|
|
|
|
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (new_name &&
|
2013-06-13 18:19:44 +00:00
|
|
|
((0 < patch->is_new) || patch->is_rename || patch->is_copy)) {
|
2016-05-24 08:10:49 +00:00
|
|
|
int err = check_to_create(state, new_name, ok_if_exists);
|
2012-06-07 21:10:19 +00:00
|
|
|
|
2016-05-24 08:10:59 +00:00
|
|
|
if (err && state->threeway) {
|
2012-06-07 22:04:11 +00:00
|
|
|
patch->direct_to_threeway = 1;
|
|
|
|
} else switch (err) {
|
2012-06-07 21:10:19 +00:00
|
|
|
case 0:
|
|
|
|
break; /* happy */
|
|
|
|
case EXISTS_IN_INDEX:
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: already exists in index"), new_name);
|
2012-06-07 21:10:19 +00:00
|
|
|
break;
|
|
|
|
case EXISTS_IN_WORKTREE:
|
|
|
|
return error(_("%s: already exists in working directory"),
|
|
|
|
new_name);
|
|
|
|
default:
|
|
|
|
return err;
|
2006-05-17 23:56:13 +00:00
|
|
|
}
|
2012-06-07 21:10:19 +00:00
|
|
|
|
2005-08-17 07:01:07 +00:00
|
|
|
if (!patch->new_mode) {
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (0 < patch->is_new)
|
2005-08-17 07:01:07 +00:00
|
|
|
patch->new_mode = S_IFREG | 0644;
|
|
|
|
else
|
|
|
|
patch->new_mode = patch->old_mode;
|
|
|
|
}
|
2005-05-26 19:25:52 +00:00
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
|
|
|
|
if (new_name && old_name) {
|
|
|
|
int same = !strcmp(old_name, new_name);
|
|
|
|
if (!patch->new_mode)
|
|
|
|
patch->new_mode = patch->old_mode;
|
2012-05-31 11:20:42 +00:00
|
|
|
if ((patch->old_mode ^ patch->new_mode) & S_IFMT) {
|
|
|
|
if (same)
|
|
|
|
return error(_("new mode (%o) of %s does not "
|
|
|
|
"match old mode (%o)"),
|
|
|
|
patch->new_mode, new_name,
|
|
|
|
patch->old_mode);
|
|
|
|
else
|
|
|
|
return error(_("new mode (%o) of %s does not "
|
|
|
|
"match old mode (%o) of %s"),
|
|
|
|
patch->new_mode, new_name,
|
|
|
|
patch->old_mode, old_name);
|
|
|
|
}
|
2006-05-15 22:15:47 +00:00
|
|
|
}
|
2005-06-05 18:03:13 +00:00
|
|
|
|
2016-08-08 21:03:15 +00:00
|
|
|
if (!state->unsafe_paths && check_unsafe_path(patch))
|
|
|
|
return -128;
|
2015-01-29 23:35:24 +00:00
|
|
|
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
/*
|
|
|
|
* An attempt to read from or delete a path that is beyond a
|
|
|
|
* symbolic link will be prevented by load_patch_target() that
|
|
|
|
* is called at the beginning of apply_data() so we do not
|
|
|
|
* have to worry about a patch marked with "is_delete" bit
|
|
|
|
* here. We however need to make sure that the patch result
|
|
|
|
* is not deposited to a path that is beyond a symbolic link
|
|
|
|
* here.
|
|
|
|
*/
|
2016-05-24 08:10:49 +00:00
|
|
|
if (!patch->is_delete && path_is_beyond_symlink(state, patch->new_name))
|
apply: do not touch a file beyond a symbolic link
Because Git tracks symbolic links as symbolic links, a path that
has a symbolic link in its leading part (e.g. path/to/dir/file,
where path/to/dir is a symbolic link to somewhere else, be it
inside or outside the working tree) can never appear in a patch
that validly applies, unless the same patch first removes the
symbolic link to allow a directory to be created there.
Detect and reject such a patch.
Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but "git
apply" can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
"git apply" first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against the
resulting tree that the patch would create by inspecting all the
patches in the input and then the target of patch application
(either the index or the working tree).
This way, we catch a mischief or a mistake to add a symbolic link
path/to/dir and a file path/to/dir/file at the same time, while
allowing a valid patch that removes a symbolic link path/to/dir and
then adds a file path/to/dir/file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29 20:41:22 +00:00
|
|
|
return error(_("affected file '%s' is beyond a symbolic link"),
|
|
|
|
patch->new_name);
|
|
|
|
|
2016-05-24 08:10:47 +00:00
|
|
|
if (apply_data(state, patch, &st, ce) < 0)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("%s: patch does not apply"), name);
|
2006-08-17 00:55:29 +00:00
|
|
|
patch->rejected = 0;
|
2005-05-26 22:10:02 +00:00
|
|
|
return 0;
|
2005-05-26 19:25:52 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:47 +00:00
|
|
|
static int check_patch_list(struct apply_state *state, struct patch *patch)
|
2005-05-26 17:23:51 +00:00
|
|
|
{
|
2006-08-23 10:39:10 +00:00
|
|
|
int err = 0;
|
2005-05-26 22:10:02 +00:00
|
|
|
|
2016-05-24 08:11:22 +00:00
|
|
|
prepare_symlink_changes(state, patch);
|
2016-05-24 08:11:21 +00:00
|
|
|
prepare_fn_table(state, patch);
|
2008-06-27 18:39:12 +00:00
|
|
|
while (patch) {
|
2016-08-08 21:03:15 +00:00
|
|
|
int res;
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely)
|
2006-08-18 10:14:48 +00:00
|
|
|
say_patch_name(stderr,
|
2012-04-23 12:30:28 +00:00
|
|
|
_("Checking patch %s..."), patch);
|
2016-08-08 21:03:15 +00:00
|
|
|
res = check_patch(state, patch);
|
|
|
|
if (res == -128)
|
|
|
|
return -128;
|
|
|
|
err |= res;
|
2008-06-27 18:39:12 +00:00
|
|
|
patch = patch->next;
|
2006-07-17 07:10:47 +00:00
|
|
|
}
|
2006-08-23 10:39:10 +00:00
|
|
|
return err;
|
2005-05-26 22:10:02 +00:00
|
|
|
}
|
|
|
|
|
2007-09-17 00:24:57 +00:00
|
|
|
/* This function tries to read the sha1 from the current index */
|
|
|
|
static int get_current_sha1(const char *path, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
if (read_cache() < 0)
|
|
|
|
return -1;
|
|
|
|
pos = cache_name_pos(path, strlen(path));
|
|
|
|
if (pos < 0)
|
|
|
|
return -1;
|
|
|
|
hashcpy(sha1, active_cache[pos]->sha1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-02-05 19:19:32 +00:00
|
|
|
static int preimage_sha1_in_gitlink_patch(struct patch *p, unsigned char sha1[20])
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* A usable gitlink patch has only one fragment (hunk) that looks like:
|
|
|
|
* @@ -1 +1 @@
|
|
|
|
* -Subproject commit <old sha1>
|
|
|
|
* +Subproject commit <new sha1>
|
|
|
|
* or
|
|
|
|
* @@ -1 +0,0 @@
|
|
|
|
* -Subproject commit <old sha1>
|
|
|
|
* for a removal patch.
|
|
|
|
*/
|
|
|
|
struct fragment *hunk = p->fragments;
|
|
|
|
static const char heading[] = "-Subproject commit ";
|
|
|
|
char *preimage;
|
|
|
|
|
|
|
|
if (/* does the patch have only one hunk? */
|
|
|
|
hunk && !hunk->next &&
|
|
|
|
/* is its preimage one line? */
|
|
|
|
hunk->oldpos == 1 && hunk->oldlines == 1 &&
|
|
|
|
/* does preimage begin with the heading? */
|
|
|
|
(preimage = memchr(hunk->patch, '\n', hunk->size)) != NULL &&
|
2013-11-30 20:55:40 +00:00
|
|
|
starts_with(++preimage, heading) &&
|
2013-02-05 19:19:32 +00:00
|
|
|
/* does it record full SHA-1? */
|
|
|
|
!get_sha1_hex(preimage + sizeof(heading) - 1, sha1) &&
|
|
|
|
preimage[sizeof(heading) + 40 - 1] == '\n' &&
|
|
|
|
/* does the abbreviated name on the index line agree with it? */
|
2013-11-30 20:55:40 +00:00
|
|
|
starts_with(preimage + sizeof(heading) - 1, p->old_sha1_prefix))
|
2013-02-05 19:19:32 +00:00
|
|
|
return 0; /* it all looks fine */
|
|
|
|
|
|
|
|
/* we may have full object name on the index line */
|
|
|
|
return get_sha1_hex(p->old_sha1_prefix, sha1);
|
|
|
|
}
|
|
|
|
|
2007-09-17 22:34:06 +00:00
|
|
|
/* Build an index that contains the just the files needed for a 3way merge */
|
2016-08-08 21:03:16 +00:00
|
|
|
static int build_fake_ancestor(struct patch *list, const char *filename)
|
2005-10-07 10:42:00 +00:00
|
|
|
{
|
|
|
|
struct patch *patch;
|
2009-06-18 17:28:43 +00:00
|
|
|
struct index_state result = { NULL };
|
2014-06-13 12:19:23 +00:00
|
|
|
static struct lock_file lock;
|
2016-08-08 21:03:16 +00:00
|
|
|
int res;
|
2005-10-07 10:42:00 +00:00
|
|
|
|
|
|
|
/* Once we start supporting the reverse patch, it may be
|
|
|
|
* worth showing the new sha1 prefix, but until then...
|
|
|
|
*/
|
|
|
|
for (patch = list; patch; patch = patch->next) {
|
|
|
|
unsigned char sha1[20];
|
2007-09-17 22:34:06 +00:00
|
|
|
struct cache_entry *ce;
|
2005-10-07 10:42:00 +00:00
|
|
|
const char *name;
|
|
|
|
|
|
|
|
name = patch->old_name ? patch->old_name : patch->new_name;
|
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 08:04:24 +00:00
|
|
|
if (0 < patch->is_new)
|
2007-09-17 22:34:06 +00:00
|
|
|
continue;
|
2005-10-15 04:54:52 +00:00
|
|
|
|
2013-02-01 03:33:27 +00:00
|
|
|
if (S_ISGITLINK(patch->old_mode)) {
|
2013-02-05 19:19:32 +00:00
|
|
|
if (!preimage_sha1_in_gitlink_patch(patch, sha1))
|
|
|
|
; /* ok, the textual part looks sane */
|
|
|
|
else
|
2016-08-08 21:03:16 +00:00
|
|
|
return error("sha1 information is lacking or "
|
|
|
|
"useless for submodule %s", name);
|
2013-02-01 03:33:27 +00:00
|
|
|
} else if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
|
2013-02-01 03:19:44 +00:00
|
|
|
; /* ok */
|
|
|
|
} else if (!patch->lines_added && !patch->lines_deleted) {
|
|
|
|
/* mode-only change: update the current */
|
|
|
|
if (get_current_sha1(patch->old_name, sha1))
|
2016-08-08 21:03:16 +00:00
|
|
|
return error("mode change for %s, which is not "
|
|
|
|
"in current HEAD", name);
|
2013-02-01 03:19:44 +00:00
|
|
|
} else
|
2016-08-08 21:03:16 +00:00
|
|
|
return error("sha1 information is lacking or useless "
|
|
|
|
"(%s).", name);
|
2013-02-01 03:19:44 +00:00
|
|
|
|
|
|
|
ce = make_cache_entry(patch->old_mode, sha1, name, 0, 0);
|
2008-10-05 02:14:40 +00:00
|
|
|
if (!ce)
|
2016-08-08 21:03:16 +00:00
|
|
|
return error(_("make_cache_entry failed for path '%s'"),
|
|
|
|
name);
|
|
|
|
if (add_index_entry(&result, ce, ADD_CACHE_OK_TO_ADD)) {
|
|
|
|
free(ce);
|
|
|
|
return error("Could not add %s to temporary index",
|
|
|
|
name);
|
|
|
|
}
|
2005-10-07 10:42:00 +00:00
|
|
|
}
|
2007-09-17 22:34:06 +00:00
|
|
|
|
2014-06-13 12:19:23 +00:00
|
|
|
hold_lock_file_for_update(&lock, filename, LOCK_DIE_ON_ERROR);
|
2016-08-08 21:03:16 +00:00
|
|
|
res = write_locked_index(&result, &lock, COMMIT_LOCK);
|
2007-09-17 22:34:06 +00:00
|
|
|
discard_index(&result);
|
2016-08-08 21:03:16 +00:00
|
|
|
|
|
|
|
if (res)
|
|
|
|
return error("Could not write temporary index to %s", filename);
|
|
|
|
|
|
|
|
return 0;
|
2005-10-07 10:42:00 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:19 +00:00
|
|
|
static void stat_patch_list(struct apply_state *state, struct patch *patch)
|
2005-05-26 22:10:02 +00:00
|
|
|
{
|
|
|
|
int files, adds, dels;
|
|
|
|
|
|
|
|
for (files = adds = dels = 0 ; patch ; patch = patch->next) {
|
|
|
|
files++;
|
|
|
|
adds += patch->lines_added;
|
|
|
|
dels += patch->lines_deleted;
|
2016-05-24 08:11:19 +00:00
|
|
|
show_stats(state, patch);
|
2005-05-26 22:10:02 +00:00
|
|
|
}
|
|
|
|
|
2012-02-01 12:55:07 +00:00
|
|
|
print_stat_summary(stdout, files, adds, dels);
|
2005-05-26 18:40:43 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:02 +00:00
|
|
|
static void numstat_patch_list(struct apply_state *state,
|
|
|
|
struct patch *patch)
|
2005-10-28 09:43:31 +00:00
|
|
|
{
|
|
|
|
for ( ; patch; patch = patch->next) {
|
|
|
|
const char *name;
|
2006-05-15 04:59:04 +00:00
|
|
|
name = patch->new_name ? patch->new_name : patch->old_name;
|
2006-11-15 06:23:18 +00:00
|
|
|
if (patch->is_binary)
|
|
|
|
printf("-\t-\t");
|
|
|
|
else
|
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
|
|
|
printf("%d\t%d\t", patch->lines_added, patch->lines_deleted);
|
2016-05-24 08:11:02 +00:00
|
|
|
write_name_quoted(name, stdout, state->line_termination);
|
2005-10-28 09:43:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-06-22 09:29:46 +00:00
|
|
|
static void show_file_mode_name(const char *newdelete, unsigned int mode, const char *name)
|
|
|
|
{
|
|
|
|
if (mode)
|
|
|
|
printf(" %s mode %06o %s\n", newdelete, mode, name);
|
|
|
|
else
|
|
|
|
printf(" %s %s\n", newdelete, name);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void show_mode_change(struct patch *p, int show_name)
|
|
|
|
{
|
|
|
|
if (p->old_mode && p->new_mode && p->old_mode != p->new_mode) {
|
|
|
|
if (show_name)
|
|
|
|
printf(" mode change %06o => %06o %s\n",
|
|
|
|
p->old_mode, p->new_mode, p->new_name);
|
|
|
|
else
|
|
|
|
printf(" mode change %06o => %06o\n",
|
|
|
|
p->old_mode, p->new_mode);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void show_rename_copy(struct patch *p)
|
|
|
|
{
|
|
|
|
const char *renamecopy = p->is_rename ? "rename" : "copy";
|
|
|
|
const char *old, *new;
|
|
|
|
|
|
|
|
/* Find common prefix */
|
|
|
|
old = p->old_name;
|
|
|
|
new = p->new_name;
|
|
|
|
while (1) {
|
|
|
|
const char *slash_old, *slash_new;
|
|
|
|
slash_old = strchr(old, '/');
|
|
|
|
slash_new = strchr(new, '/');
|
|
|
|
if (!slash_old ||
|
|
|
|
!slash_new ||
|
|
|
|
slash_old - old != slash_new - new ||
|
|
|
|
memcmp(old, new, slash_new - new))
|
|
|
|
break;
|
|
|
|
old = slash_old + 1;
|
|
|
|
new = slash_new + 1;
|
|
|
|
}
|
|
|
|
/* p->old_name thru old is the common prefix, and old and new
|
|
|
|
* through the end of names are renames
|
|
|
|
*/
|
|
|
|
if (old != p->old_name)
|
|
|
|
printf(" %s %.*s{%s => %s} (%d%%)\n", renamecopy,
|
2005-07-12 18:54:21 +00:00
|
|
|
(int)(old - p->old_name), p->old_name,
|
2005-06-22 09:29:46 +00:00
|
|
|
old, new, p->score);
|
|
|
|
else
|
|
|
|
printf(" %s %s => %s (%d%%)\n", renamecopy,
|
|
|
|
p->old_name, p->new_name, p->score);
|
|
|
|
show_mode_change(p, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void summary_patch_list(struct patch *patch)
|
|
|
|
{
|
|
|
|
struct patch *p;
|
|
|
|
|
|
|
|
for (p = patch; p; p = p->next) {
|
|
|
|
if (p->is_new)
|
|
|
|
show_file_mode_name("create", p->new_mode, p->new_name);
|
|
|
|
else if (p->is_delete)
|
|
|
|
show_file_mode_name("delete", p->old_mode, p->old_name);
|
|
|
|
else {
|
|
|
|
if (p->is_rename || p->is_copy)
|
|
|
|
show_rename_copy(p);
|
|
|
|
else {
|
|
|
|
if (p->score) {
|
|
|
|
printf(" rewrite %s (%d%%)\n",
|
|
|
|
p->new_name, p->score);
|
|
|
|
show_mode_change(p, 0);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
show_mode_change(p, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-24 08:11:19 +00:00
|
|
|
static void patch_stats(struct apply_state *state, struct patch *patch)
|
2005-05-26 18:40:43 +00:00
|
|
|
{
|
|
|
|
int lines = patch->lines_added + patch->lines_deleted;
|
|
|
|
|
2016-05-24 08:11:19 +00:00
|
|
|
if (lines > state->max_change)
|
|
|
|
state->max_change = lines;
|
2005-05-26 18:40:43 +00:00
|
|
|
if (patch->old_name) {
|
2005-10-15 04:54:52 +00:00
|
|
|
int len = quote_c_style(patch->old_name, NULL, NULL, 0);
|
|
|
|
if (!len)
|
|
|
|
len = strlen(patch->old_name);
|
2016-05-24 08:11:19 +00:00
|
|
|
if (len > state->max_len)
|
|
|
|
state->max_len = len;
|
2005-05-26 18:40:43 +00:00
|
|
|
}
|
|
|
|
if (patch->new_name) {
|
2005-10-15 04:54:52 +00:00
|
|
|
int len = quote_c_style(patch->new_name, NULL, NULL, 0);
|
|
|
|
if (!len)
|
|
|
|
len = strlen(patch->new_name);
|
2016-05-24 08:11:19 +00:00
|
|
|
if (len > state->max_len)
|
|
|
|
state->max_len = len;
|
2005-05-26 18:40:43 +00:00
|
|
|
}
|
2005-05-26 17:23:51 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:17 +00:00
|
|
|
static int remove_file(struct apply_state *state, struct patch *patch, int rmdir_empty)
|
2005-06-05 21:05:43 +00:00
|
|
|
{
|
2016-05-24 08:10:53 +00:00
|
|
|
if (state->update_index) {
|
2005-06-05 21:05:43 +00:00
|
|
|
if (remove_file_from_cache(patch->old_name) < 0)
|
2016-08-08 21:03:17 +00:00
|
|
|
return error(_("unable to remove %s from index"), patch->old_name);
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
2016-05-24 08:10:55 +00:00
|
|
|
if (!state->cached) {
|
2010-03-26 15:25:34 +00:00
|
|
|
if (!remove_or_warn(patch->old_mode, patch->old_name) && rmdir_empty) {
|
2008-09-26 22:59:14 +00:00
|
|
|
remove_path(patch->old_name);
|
2007-01-09 20:25:46 +00:00
|
|
|
}
|
|
|
|
}
|
2016-08-08 21:03:17 +00:00
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:19 +00:00
|
|
|
static int add_index_file(struct apply_state *state,
|
|
|
|
const char *path,
|
|
|
|
unsigned mode,
|
|
|
|
void *buf,
|
|
|
|
unsigned long size)
|
2005-06-05 21:05:43 +00:00
|
|
|
{
|
|
|
|
struct stat st;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
int namelen = strlen(path);
|
|
|
|
unsigned ce_size = cache_entry_size(namelen);
|
|
|
|
|
2016-05-24 08:10:53 +00:00
|
|
|
if (!state->update_index)
|
2016-08-08 21:03:19 +00:00
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2006-04-03 18:30:46 +00:00
|
|
|
ce = xcalloc(1, ce_size);
|
2005-06-05 21:05:43 +00:00
|
|
|
memcpy(ce->name, path, namelen);
|
|
|
|
ce->ce_mode = create_ce_mode(mode);
|
2012-07-11 09:22:37 +00:00
|
|
|
ce->ce_flags = create_ce_flags(0);
|
|
|
|
ce->ce_namelen = namelen;
|
2007-08-15 17:22:09 +00:00
|
|
|
if (S_ISGITLINK(mode)) {
|
2014-06-18 19:45:34 +00:00
|
|
|
const char *s;
|
2007-08-15 17:22:09 +00:00
|
|
|
|
2014-06-18 19:45:34 +00:00
|
|
|
if (!skip_prefix(buf, "Subproject commit ", &s) ||
|
2016-08-08 21:03:19 +00:00
|
|
|
get_sha1_hex(s, ce->sha1)) {
|
|
|
|
free(ce);
|
|
|
|
return error(_("corrupt patch for submodule %s"), path);
|
|
|
|
}
|
2007-08-15 17:22:09 +00:00
|
|
|
} else {
|
2016-05-24 08:10:55 +00:00
|
|
|
if (!state->cached) {
|
2016-08-08 21:03:19 +00:00
|
|
|
if (lstat(path, &st) < 0) {
|
|
|
|
free(ce);
|
|
|
|
return error(_("unable to stat newly "
|
|
|
|
"created file '%s': %s"),
|
|
|
|
path, strerror(errno));
|
|
|
|
}
|
2007-08-15 17:22:09 +00:00
|
|
|
fill_stat_cache_info(ce, &st);
|
|
|
|
}
|
2016-08-08 21:03:19 +00:00
|
|
|
if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0) {
|
|
|
|
free(ce);
|
|
|
|
return error(_("unable to create backing store "
|
|
|
|
"for newly created file %s"), path);
|
|
|
|
}
|
2006-05-15 22:15:47 +00:00
|
|
|
}
|
2016-08-08 21:03:19 +00:00
|
|
|
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0) {
|
|
|
|
free(ce);
|
|
|
|
return error(_("unable to add cache entry for %s"), path);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:18 +00:00
|
|
|
/*
|
|
|
|
* Returns:
|
|
|
|
* -1 if an unrecoverable error happened
|
|
|
|
* 0 if everything went well
|
|
|
|
* 1 if a recoverable error happened
|
|
|
|
*/
|
2005-07-14 00:25:53 +00:00
|
|
|
static int try_create_file(const char *path, unsigned int mode, const char *buf, unsigned long size)
|
|
|
|
{
|
2016-09-04 20:18:18 +00:00
|
|
|
int fd, res;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf nbuf = STRBUF_INIT;
|
2005-07-14 00:25:53 +00:00
|
|
|
|
2007-08-15 17:22:09 +00:00
|
|
|
if (S_ISGITLINK(mode)) {
|
|
|
|
struct stat st;
|
|
|
|
if (!lstat(path, &st) && S_ISDIR(st.st_mode))
|
|
|
|
return 0;
|
2016-09-04 20:18:18 +00:00
|
|
|
return !!mkdir(path, 0777);
|
2007-08-15 17:22:09 +00:00
|
|
|
}
|
|
|
|
|
2007-03-02 21:11:30 +00:00
|
|
|
if (has_symlinks && S_ISLNK(mode))
|
2006-08-10 05:47:25 +00:00
|
|
|
/* Although buf:size is counted string, it also is NUL
|
|
|
|
* terminated.
|
|
|
|
*/
|
2016-09-04 20:18:18 +00:00
|
|
|
return !!symlink(buf, path);
|
2007-03-23 00:32:51 +00:00
|
|
|
|
|
|
|
fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
|
|
|
|
if (fd < 0)
|
2016-09-04 20:18:18 +00:00
|
|
|
return 1;
|
2007-03-23 00:32:51 +00:00
|
|
|
|
Rewrite convert_to_{git,working_tree} to use strbuf's.
* Now, those functions take an "out" strbuf argument, where they store their
result if any. In that case, it also returns 1, else it returns 0.
* those functions support "in place" editing, in the sense that it's OK to
call them this way:
convert_to_git(path, sb->buf, sb->len, sb);
When doable, conversions are done in place for real, else the strbuf
content is just replaced with the new one, transparentely for the caller.
If you want to create a new filter working this way, being the accumulation
of filter1, filter2, ... filtern, then your meta_filter would be:
int meta_filter(..., const char *src, size_t len, struct strbuf *sb)
{
int ret = 0;
ret |= filter1(...., src, len, sb);
if (ret) {
src = sb->buf;
len = sb->len;
}
ret |= filter2(...., src, len, sb);
if (ret) {
src = sb->buf;
len = sb->len;
}
....
return ret | filtern(..., src, len, sb);
}
That's why subfilters the convert_to_* functions called were also rewritten
to work this way.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16 13:51:04 +00:00
|
|
|
if (convert_to_working_tree(path, buf, size, &nbuf)) {
|
|
|
|
size = nbuf.len;
|
|
|
|
buf = nbuf.buf;
|
2005-07-14 00:25:53 +00:00
|
|
|
}
|
2016-09-04 20:18:18 +00:00
|
|
|
|
|
|
|
res = write_in_full(fd, buf, size) < 0;
|
|
|
|
if (res)
|
|
|
|
error_errno(_("failed to write to '%s'"), path);
|
2007-09-16 16:54:42 +00:00
|
|
|
strbuf_release(&nbuf);
|
2007-04-19 00:05:03 +00:00
|
|
|
|
2016-09-04 20:18:18 +00:00
|
|
|
if (close(fd) < 0 && !res)
|
|
|
|
return error_errno(_("closing file '%s'"), path);
|
|
|
|
|
|
|
|
return res ? -1 : 0;
|
2005-07-14 00:25:53 +00:00
|
|
|
}
|
|
|
|
|
2005-06-22 02:10:21 +00:00
|
|
|
/*
|
|
|
|
* We optimistically assume that the directories exist,
|
|
|
|
* which is true 99% of the time anyway. If they don't,
|
|
|
|
* we create them and try again.
|
2016-09-04 20:18:19 +00:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* -1 on error
|
|
|
|
* 0 otherwise
|
2005-06-22 02:10:21 +00:00
|
|
|
*/
|
2016-09-04 20:18:19 +00:00
|
|
|
static int create_one_file(struct apply_state *state,
|
|
|
|
char *path,
|
|
|
|
unsigned mode,
|
|
|
|
const char *buf,
|
|
|
|
unsigned long size)
|
2005-06-22 02:10:21 +00:00
|
|
|
{
|
2016-09-04 20:18:18 +00:00
|
|
|
int res;
|
|
|
|
|
2016-05-24 08:10:55 +00:00
|
|
|
if (state->cached)
|
2016-09-04 20:18:19 +00:00
|
|
|
return 0;
|
2016-09-04 20:18:18 +00:00
|
|
|
|
|
|
|
res = try_create_file(path, mode, buf, size);
|
|
|
|
if (res < 0)
|
2016-09-04 20:18:19 +00:00
|
|
|
return -1;
|
2016-09-04 20:18:18 +00:00
|
|
|
if (!res)
|
2016-09-04 20:18:19 +00:00
|
|
|
return 0;
|
2005-06-22 02:10:21 +00:00
|
|
|
|
2005-07-14 00:25:53 +00:00
|
|
|
if (errno == ENOENT) {
|
2006-02-04 06:50:57 +00:00
|
|
|
if (safe_create_leading_directories(path))
|
2016-09-04 20:18:19 +00:00
|
|
|
return 0;
|
2016-09-04 20:18:18 +00:00
|
|
|
res = try_create_file(path, mode, buf, size);
|
|
|
|
if (res < 0)
|
2016-09-04 20:18:19 +00:00
|
|
|
return -1;
|
2016-09-04 20:18:18 +00:00
|
|
|
if (!res)
|
2016-09-04 20:18:19 +00:00
|
|
|
return 0;
|
2005-06-22 02:10:21 +00:00
|
|
|
}
|
|
|
|
|
2006-07-18 17:46:34 +00:00
|
|
|
if (errno == EEXIST || errno == EACCES) {
|
2006-07-17 06:28:23 +00:00
|
|
|
/* We may be trying to create a file where a directory
|
|
|
|
* used to be.
|
|
|
|
*/
|
|
|
|
struct stat st;
|
2007-04-18 21:58:56 +00:00
|
|
|
if (!lstat(path, &st) && (!S_ISDIR(st.st_mode) || !rmdir(path)))
|
2006-07-17 06:28:23 +00:00
|
|
|
errno = EEXIST;
|
|
|
|
}
|
|
|
|
|
2005-07-14 00:25:53 +00:00
|
|
|
if (errno == EEXIST) {
|
|
|
|
unsigned int nr = getpid();
|
2005-06-22 02:10:21 +00:00
|
|
|
|
2005-07-14 00:25:53 +00:00
|
|
|
for (;;) {
|
2008-10-26 22:08:52 +00:00
|
|
|
char newpath[PATH_MAX];
|
|
|
|
mksnpath(newpath, sizeof(newpath), "%s~%u", path, nr);
|
2016-09-04 20:18:18 +00:00
|
|
|
res = try_create_file(newpath, mode, buf, size);
|
|
|
|
if (res < 0)
|
2016-09-04 20:18:19 +00:00
|
|
|
return -1;
|
2016-09-04 20:18:18 +00:00
|
|
|
if (!res) {
|
2005-07-14 00:25:53 +00:00
|
|
|
if (!rename(newpath, path))
|
2016-09-04 20:18:19 +00:00
|
|
|
return 0;
|
2009-04-29 21:22:56 +00:00
|
|
|
unlink_or_warn(newpath);
|
2005-07-14 00:25:53 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (errno != EEXIST)
|
|
|
|
break;
|
2006-01-05 09:00:12 +00:00
|
|
|
++nr;
|
|
|
|
}
|
2005-06-22 02:10:21 +00:00
|
|
|
}
|
2016-09-04 20:18:19 +00:00
|
|
|
return error_errno(_("unable to write file '%s' mode %o"),
|
|
|
|
path, mode);
|
2005-06-22 02:10:21 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:18 +00:00
|
|
|
static int add_conflicted_stages_file(struct apply_state *state,
|
2016-05-24 08:10:53 +00:00
|
|
|
struct patch *patch)
|
2012-05-09 23:50:58 +00:00
|
|
|
{
|
|
|
|
int stage, namelen;
|
|
|
|
unsigned ce_size, mode;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
2016-05-24 08:10:53 +00:00
|
|
|
if (!state->update_index)
|
2016-08-08 21:03:18 +00:00
|
|
|
return 0;
|
2012-05-09 23:50:58 +00:00
|
|
|
namelen = strlen(patch->new_name);
|
|
|
|
ce_size = cache_entry_size(namelen);
|
|
|
|
mode = patch->new_mode ? patch->new_mode : (S_IFREG | 0644);
|
|
|
|
|
|
|
|
remove_file_from_cache(patch->new_name);
|
|
|
|
for (stage = 1; stage < 4; stage++) {
|
2015-03-13 23:39:36 +00:00
|
|
|
if (is_null_oid(&patch->threeway_stage[stage - 1]))
|
2012-05-09 23:50:58 +00:00
|
|
|
continue;
|
|
|
|
ce = xcalloc(1, ce_size);
|
|
|
|
memcpy(ce->name, patch->new_name, namelen);
|
|
|
|
ce->ce_mode = create_ce_mode(mode);
|
2012-07-24 03:55:16 +00:00
|
|
|
ce->ce_flags = create_ce_flags(stage);
|
|
|
|
ce->ce_namelen = namelen;
|
2015-03-13 23:39:36 +00:00
|
|
|
hashcpy(ce->sha1, patch->threeway_stage[stage - 1].hash);
|
2016-08-08 21:03:18 +00:00
|
|
|
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0) {
|
|
|
|
free(ce);
|
|
|
|
return error(_("unable to add cache entry for %s"),
|
|
|
|
patch->new_name);
|
|
|
|
}
|
2012-05-09 23:50:58 +00:00
|
|
|
}
|
2016-08-08 21:03:18 +00:00
|
|
|
|
|
|
|
return 0;
|
2012-05-09 23:50:58 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:20 +00:00
|
|
|
static int create_file(struct apply_state *state, struct patch *patch)
|
2005-06-05 21:05:43 +00:00
|
|
|
{
|
2006-02-04 06:50:57 +00:00
|
|
|
char *path = patch->new_name;
|
2005-06-05 21:05:43 +00:00
|
|
|
unsigned mode = patch->new_mode;
|
|
|
|
unsigned long size = patch->resultsize;
|
|
|
|
char *buf = patch->result;
|
|
|
|
|
|
|
|
if (!mode)
|
|
|
|
mode = S_IFREG | 0644;
|
2016-09-04 20:18:19 +00:00
|
|
|
if (create_one_file(state, path, mode, buf, size))
|
|
|
|
return -1;
|
2012-05-09 23:50:58 +00:00
|
|
|
|
2016-08-08 21:03:20 +00:00
|
|
|
if (patch->conflicted_threeway)
|
|
|
|
return add_conflicted_stages_file(state, patch);
|
|
|
|
else
|
|
|
|
return add_index_file(state, path, mode, buf, size);
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2006-07-17 06:52:09 +00:00
|
|
|
/* phase zero is to remove, phase one is to create */
|
2016-08-08 21:03:21 +00:00
|
|
|
static int write_out_one_result(struct apply_state *state,
|
|
|
|
struct patch *patch,
|
|
|
|
int phase)
|
2005-06-05 21:05:43 +00:00
|
|
|
{
|
|
|
|
if (patch->is_delete > 0) {
|
2016-08-08 21:03:21 +00:00
|
|
|
if (phase == 0)
|
|
|
|
return remove_file(state, patch, 1);
|
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
if (patch->is_new > 0 || patch->is_copy) {
|
2016-08-08 21:03:21 +00:00
|
|
|
if (phase == 1)
|
|
|
|
return create_file(state, patch);
|
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Rename or modification boils down to the same
|
|
|
|
* thing: remove the old, write the new
|
|
|
|
*/
|
2016-08-08 21:03:21 +00:00
|
|
|
if (phase == 0)
|
|
|
|
return remove_file(state, patch, patch->is_rename);
|
|
|
|
if (phase == 1)
|
|
|
|
return create_file(state, patch);
|
|
|
|
return 0;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 08:10:52 +00:00
|
|
|
static int write_out_one_reject(struct apply_state *state, struct patch *patch)
|
2006-08-17 00:55:29 +00:00
|
|
|
{
|
2006-08-18 10:10:19 +00:00
|
|
|
FILE *rej;
|
|
|
|
char namebuf[PATH_MAX];
|
2006-08-17 00:55:29 +00:00
|
|
|
struct fragment *frag;
|
2006-08-18 10:10:19 +00:00
|
|
|
int cnt = 0;
|
2012-04-23 12:30:28 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2006-08-17 00:55:29 +00:00
|
|
|
|
2006-08-18 10:10:19 +00:00
|
|
|
for (cnt = 0, frag = patch->fragments; frag; frag = frag->next) {
|
2006-08-17 00:55:29 +00:00
|
|
|
if (!frag->rejected)
|
|
|
|
continue;
|
2006-08-18 10:10:19 +00:00
|
|
|
cnt++;
|
|
|
|
}
|
|
|
|
|
2006-08-18 10:14:48 +00:00
|
|
|
if (!cnt) {
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely)
|
2006-08-18 10:14:48 +00:00
|
|
|
say_patch_name(stderr,
|
2012-04-23 12:30:28 +00:00
|
|
|
_("Applied patch %s cleanly."), patch);
|
2006-08-18 10:10:19 +00:00
|
|
|
return 0;
|
2006-08-18 10:14:48 +00:00
|
|
|
}
|
2006-08-18 10:10:19 +00:00
|
|
|
|
|
|
|
/* This should not happen, because a removal patch that leaves
|
|
|
|
* contents are marked "rejected" at the patch level.
|
|
|
|
*/
|
|
|
|
if (!patch->new_name)
|
2012-04-23 12:30:27 +00:00
|
|
|
die(_("internal error"));
|
2006-08-18 10:10:19 +00:00
|
|
|
|
2006-08-18 10:14:48 +00:00
|
|
|
/* Say this even without --verbose */
|
2012-04-23 12:30:28 +00:00
|
|
|
strbuf_addf(&sb, Q_("Applying patch %%s with %d reject...",
|
|
|
|
"Applying patch %%s with %d rejects...",
|
|
|
|
cnt),
|
|
|
|
cnt);
|
|
|
|
say_patch_name(stderr, sb.buf, patch);
|
|
|
|
strbuf_release(&sb);
|
2006-08-18 10:14:48 +00:00
|
|
|
|
2006-08-18 10:10:19 +00:00
|
|
|
cnt = strlen(patch->new_name);
|
|
|
|
if (ARRAY_SIZE(namebuf) <= cnt + 5) {
|
|
|
|
cnt = ARRAY_SIZE(namebuf) - 5;
|
2012-04-23 12:30:27 +00:00
|
|
|
warning(_("truncating .rej filename to %.*s.rej"),
|
2006-08-18 10:10:19 +00:00
|
|
|
cnt - 1, patch->new_name);
|
|
|
|
}
|
|
|
|
memcpy(namebuf, patch->new_name, cnt);
|
|
|
|
memcpy(namebuf + cnt, ".rej", 5);
|
|
|
|
|
|
|
|
rej = fopen(namebuf, "w");
|
|
|
|
if (!rej)
|
2012-04-23 12:30:27 +00:00
|
|
|
return error(_("cannot open %s: %s"), namebuf, strerror(errno));
|
2006-08-18 10:10:19 +00:00
|
|
|
|
|
|
|
/* Normal git tools never deal with .rej, so do not pretend
|
2014-03-31 22:11:46 +00:00
|
|
|
* this is a git patch by saying --git or giving extended
|
2006-08-18 10:10:19 +00:00
|
|
|
* headers. While at it, maybe please "kompare" that wants
|
|
|
|
* the trailing TAB and some garbage at the end of line ;-).
|
|
|
|
*/
|
|
|
|
fprintf(rej, "diff a/%s b/%s\t(rejected hunks)\n",
|
|
|
|
patch->new_name, patch->new_name);
|
2006-08-22 22:49:28 +00:00
|
|
|
for (cnt = 1, frag = patch->fragments;
|
2006-08-18 10:10:19 +00:00
|
|
|
frag;
|
|
|
|
cnt++, frag = frag->next) {
|
|
|
|
if (!frag->rejected) {
|
2012-04-23 12:30:27 +00:00
|
|
|
fprintf_ln(stderr, _("Hunk #%d applied cleanly."), cnt);
|
2006-08-18 10:10:19 +00:00
|
|
|
continue;
|
2006-08-17 00:55:29 +00:00
|
|
|
}
|
2012-04-23 12:30:27 +00:00
|
|
|
fprintf_ln(stderr, _("Rejected hunk #%d."), cnt);
|
2006-08-18 10:10:19 +00:00
|
|
|
fprintf(rej, "%.*s", frag->size, frag->patch);
|
2006-08-17 00:55:29 +00:00
|
|
|
if (frag->patch[frag->size-1] != '\n')
|
2006-08-18 10:10:19 +00:00
|
|
|
fputc('\n', rej);
|
2006-08-17 00:55:29 +00:00
|
|
|
}
|
2006-08-18 10:10:19 +00:00
|
|
|
fclose(rej);
|
|
|
|
return -1;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:22 +00:00
|
|
|
/*
|
|
|
|
* Returns:
|
|
|
|
* -1 if an error happened
|
|
|
|
* 0 if the patch applied cleanly
|
|
|
|
* 1 if the patch did not apply cleanly
|
|
|
|
*/
|
2016-05-24 08:10:52 +00:00
|
|
|
static int write_out_results(struct apply_state *state, struct patch *list)
|
2005-06-05 21:05:43 +00:00
|
|
|
{
|
2006-07-17 06:52:09 +00:00
|
|
|
int phase;
|
2006-08-17 00:55:29 +00:00
|
|
|
int errs = 0;
|
|
|
|
struct patch *l;
|
2012-05-09 23:50:58 +00:00
|
|
|
struct string_list cpath = STRING_LIST_INIT_DUP;
|
2006-07-17 06:52:09 +00:00
|
|
|
|
|
|
|
for (phase = 0; phase < 2; phase++) {
|
2006-08-17 00:55:29 +00:00
|
|
|
l = list;
|
2006-07-17 06:52:09 +00:00
|
|
|
while (l) {
|
2006-08-17 00:55:29 +00:00
|
|
|
if (l->rejected)
|
|
|
|
errs = 1;
|
2006-08-18 10:10:19 +00:00
|
|
|
else {
|
2016-08-08 21:03:22 +00:00
|
|
|
if (write_out_one_result(state, l, phase)) {
|
|
|
|
string_list_clear(&cpath, 0);
|
|
|
|
return -1;
|
|
|
|
}
|
2012-05-09 23:50:58 +00:00
|
|
|
if (phase == 1) {
|
2016-05-24 08:10:52 +00:00
|
|
|
if (write_out_one_reject(state, l))
|
2012-05-09 23:50:58 +00:00
|
|
|
errs = 1;
|
|
|
|
if (l->conflicted_threeway) {
|
|
|
|
string_list_append(&cpath, l->new_name);
|
|
|
|
errs = 1;
|
|
|
|
}
|
|
|
|
}
|
2006-08-17 00:55:29 +00:00
|
|
|
}
|
2006-07-17 06:52:09 +00:00
|
|
|
l = l->next;
|
|
|
|
}
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
2012-05-09 23:50:58 +00:00
|
|
|
|
|
|
|
if (cpath.nr) {
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
2014-11-25 08:02:35 +00:00
|
|
|
string_list_sort(&cpath);
|
2012-05-09 23:50:58 +00:00
|
|
|
for_each_string_list_item(item, &cpath)
|
|
|
|
fprintf(stderr, "U %s\n", item->string);
|
|
|
|
string_list_clear(&cpath, 0);
|
2012-05-10 20:56:49 +00:00
|
|
|
|
|
|
|
rerere(0);
|
2012-05-09 23:50:58 +00:00
|
|
|
}
|
|
|
|
|
2006-08-17 00:55:29 +00:00
|
|
|
return errs;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2006-06-06 19:51:49 +00:00
|
|
|
static struct lock_file lock_file;
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2008-06-27 17:43:09 +00:00
|
|
|
#define INACCURATE_EOF (1<<0)
|
|
|
|
#define RECOUNT (1<<1)
|
|
|
|
|
2016-08-08 21:03:00 +00:00
|
|
|
/*
|
|
|
|
* Try to apply a patch.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* -128 if a bad error happened (like patch unreadable)
|
|
|
|
* -1 if patch did not apply and user cannot deal with it
|
|
|
|
* 0 if the patch applied
|
|
|
|
* 1 if the patch did not apply but user might fix it
|
|
|
|
*/
|
2016-05-11 13:16:19 +00:00
|
|
|
static int apply_patch(struct apply_state *state,
|
|
|
|
int fd,
|
|
|
|
const char *filename,
|
|
|
|
int options)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
2007-09-27 11:33:19 +00:00
|
|
|
size_t offset;
|
2012-04-11 21:43:48 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT; /* owns the patch text */
|
2005-05-26 17:23:51 +00:00
|
|
|
struct patch *list = NULL, **listp = &list;
|
2005-07-22 16:56:57 +00:00
|
|
|
int skipped_patch = 0;
|
2016-08-08 21:03:00 +00:00
|
|
|
int res = 0;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2016-05-24 08:11:06 +00:00
|
|
|
state->patch_input_file = filename;
|
2016-08-08 21:03:01 +00:00
|
|
|
if (read_patch_file(&buf, fd) < 0)
|
|
|
|
return -128;
|
2005-05-23 17:52:17 +00:00
|
|
|
offset = 0;
|
2007-09-27 11:33:19 +00:00
|
|
|
while (offset < buf.len) {
|
2005-05-26 17:23:51 +00:00
|
|
|
struct patch *patch;
|
|
|
|
int nr;
|
|
|
|
|
2006-04-03 18:30:46 +00:00
|
|
|
patch = xcalloc(1, sizeof(*patch));
|
2008-06-27 17:43:09 +00:00
|
|
|
patch->inaccurate_eof = !!(options & INACCURATE_EOF);
|
|
|
|
patch->recount = !!(options & RECOUNT);
|
2016-05-11 13:16:19 +00:00
|
|
|
nr = parse_chunk(state, buf.buf + offset, buf.len - offset, patch);
|
2016-03-16 19:35:11 +00:00
|
|
|
if (nr < 0) {
|
|
|
|
free_patch(patch);
|
2016-08-08 21:03:03 +00:00
|
|
|
if (nr == -128) {
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2005-05-23 17:52:17 +00:00
|
|
|
break;
|
2016-03-16 19:35:11 +00:00
|
|
|
}
|
2016-05-24 08:10:50 +00:00
|
|
|
if (state->apply_in_reverse)
|
2006-07-28 15:46:11 +00:00
|
|
|
reverse_patches(patch);
|
2016-05-11 13:16:19 +00:00
|
|
|
if (use_patch(state, patch)) {
|
2016-05-24 08:11:19 +00:00
|
|
|
patch_stats(state, patch);
|
2005-07-22 16:56:57 +00:00
|
|
|
*listp = patch;
|
|
|
|
listp = &patch->next;
|
2007-02-20 01:57:29 +00:00
|
|
|
}
|
|
|
|
else {
|
2016-05-24 08:10:52 +00:00
|
|
|
if (state->apply_verbosely)
|
2016-03-24 11:56:19 +00:00
|
|
|
say_patch_name(stderr, _("Skipped patch '%s'."), patch);
|
2012-03-07 22:21:25 +00:00
|
|
|
free_patch(patch);
|
2005-07-22 16:56:57 +00:00
|
|
|
skipped_patch++;
|
|
|
|
}
|
2005-05-23 17:52:17 +00:00
|
|
|
offset += nr;
|
|
|
|
}
|
2005-05-26 17:23:51 +00:00
|
|
|
|
2016-08-08 21:03:00 +00:00
|
|
|
if (!list && !skipped_patch) {
|
|
|
|
error(_("unrecognized input"));
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2011-12-03 20:35:50 +00:00
|
|
|
|
2016-05-24 08:11:17 +00:00
|
|
|
if (state->whitespace_error && (state->ws_error_action == die_on_ws_error))
|
2016-05-24 08:11:05 +00:00
|
|
|
state->apply = 0;
|
2006-02-27 02:13:25 +00:00
|
|
|
|
2016-05-24 08:11:05 +00:00
|
|
|
state->update_index = state->check_index && state->apply;
|
2016-06-03 16:58:52 +00:00
|
|
|
if (state->update_index && state->newfd < 0)
|
|
|
|
state->newfd = hold_locked_index(state->lock_file, 1);
|
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-01 06:09:02 +00:00
|
|
|
|
2016-08-08 21:03:00 +00:00
|
|
|
if (state->check_index && read_cache() < 0) {
|
|
|
|
error(_("unable to read index file"));
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
2005-06-05 21:05:43 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 21:03:15 +00:00
|
|
|
if (state->check || state->apply) {
|
|
|
|
int r = check_patch_list(state, list);
|
|
|
|
if (r == -128) {
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
if (r < 0 && !state->apply_with_reject) {
|
|
|
|
res = -1;
|
|
|
|
goto end;
|
|
|
|
}
|
2016-08-08 21:03:00 +00:00
|
|
|
}
|
2005-05-26 22:10:02 +00:00
|
|
|
|
2016-08-08 21:03:22 +00:00
|
|
|
if (state->apply) {
|
|
|
|
int write_res = write_out_results(state, list);
|
|
|
|
if (write_res < 0) {
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
if (write_res > 0) {
|
|
|
|
/* with --3way, we still need to write the index out */
|
|
|
|
res = state->apply_with_reject ? -1 : 1;
|
|
|
|
goto end;
|
|
|
|
}
|
2012-05-09 23:50:58 +00:00
|
|
|
}
|
2005-06-05 21:05:43 +00:00
|
|
|
|
2016-08-08 21:03:16 +00:00
|
|
|
if (state->fake_ancestor &&
|
|
|
|
build_fake_ancestor(list, state->fake_ancestor)) {
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2005-10-07 10:42:00 +00:00
|
|
|
|
2016-05-24 08:10:56 +00:00
|
|
|
if (state->diffstat)
|
2016-05-24 08:11:19 +00:00
|
|
|
stat_patch_list(state, list);
|
2005-05-26 17:23:51 +00:00
|
|
|
|
2016-05-24 08:10:57 +00:00
|
|
|
if (state->numstat)
|
2016-05-24 08:11:02 +00:00
|
|
|
numstat_patch_list(state, list);
|
2005-10-28 09:43:31 +00:00
|
|
|
|
2016-05-24 08:10:58 +00:00
|
|
|
if (state->summary)
|
2005-06-22 09:29:46 +00:00
|
|
|
summary_patch_list(list);
|
|
|
|
|
2016-08-08 21:03:00 +00:00
|
|
|
end:
|
2012-03-27 22:10:01 +00:00
|
|
|
free_patch_list(list);
|
2007-09-27 11:33:19 +00:00
|
|
|
strbuf_release(&buf);
|
2016-05-24 08:11:21 +00:00
|
|
|
string_list_clear(&state->fn_table, 0);
|
2016-08-08 21:03:00 +00:00
|
|
|
return res;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_exclude(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
2008-12-27 23:03:57 +00:00
|
|
|
{
|
2016-05-24 08:11:07 +00:00
|
|
|
struct apply_state *state = opt->value;
|
|
|
|
add_name_limit(state, arg, 1);
|
2008-12-27 23:03:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_include(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
2008-12-27 23:03:57 +00:00
|
|
|
{
|
2016-05-24 08:11:07 +00:00
|
|
|
struct apply_state *state = opt->value;
|
|
|
|
add_name_limit(state, arg, 0);
|
2016-05-24 08:11:08 +00:00
|
|
|
state->has_include = 1;
|
2008-12-27 23:03:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_p(const struct option *opt,
|
|
|
|
const char *arg,
|
|
|
|
int unset)
|
2008-12-27 23:03:57 +00:00
|
|
|
{
|
2016-05-24 08:11:09 +00:00
|
|
|
struct apply_state *state = opt->value;
|
|
|
|
state->p_value = atoi(arg);
|
2016-05-24 08:11:10 +00:00
|
|
|
state->p_value_known = 1;
|
2008-12-27 23:03:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_space_change(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
2009-08-04 11:16:49 +00:00
|
|
|
{
|
2016-05-24 08:11:18 +00:00
|
|
|
struct apply_state *state = opt->value;
|
2009-08-04 11:16:49 +00:00
|
|
|
if (unset)
|
2016-05-24 08:11:18 +00:00
|
|
|
state->ws_ignore_action = ignore_ws_none;
|
2009-08-04 11:16:49 +00:00
|
|
|
else
|
2016-05-24 08:11:18 +00:00
|
|
|
state->ws_ignore_action = ignore_ws_change;
|
2009-08-04 11:16:49 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_whitespace(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
2008-12-27 23:03:57 +00:00
|
|
|
{
|
2016-05-24 08:11:13 +00:00
|
|
|
struct apply_state *state = opt->value;
|
|
|
|
state->whitespace_option = arg;
|
2016-08-08 21:03:05 +00:00
|
|
|
if (parse_whitespace_option(state, arg))
|
|
|
|
exit(1);
|
2008-12-27 23:03:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-04 20:18:20 +00:00
|
|
|
static int apply_option_parse_directory(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
2008-12-27 23:03:57 +00:00
|
|
|
{
|
2016-05-24 08:11:11 +00:00
|
|
|
struct apply_state *state = opt->value;
|
|
|
|
strbuf_reset(&state->root);
|
|
|
|
strbuf_addstr(&state->root, arg);
|
|
|
|
strbuf_complete(&state->root, '/');
|
2008-12-27 23:03:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2006-02-27 22:47:45 +00:00
|
|
|
|
2016-05-24 08:11:24 +00:00
|
|
|
static int apply_all_patches(struct apply_state *state,
|
|
|
|
int argc,
|
|
|
|
const char **argv,
|
|
|
|
int options)
|
2005-05-23 17:52:17 +00:00
|
|
|
{
|
|
|
|
int i;
|
2016-08-08 21:03:00 +00:00
|
|
|
int res;
|
2006-08-17 00:55:29 +00:00
|
|
|
int errs = 0;
|
2016-05-24 08:11:24 +00:00
|
|
|
int read_stdin = 1;
|
|
|
|
|
|
|
|
for (i = 0; i < argc; i++) {
|
|
|
|
const char *arg = argv[i];
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (!strcmp(arg, "-")) {
|
2016-08-08 21:03:00 +00:00
|
|
|
res = apply_patch(state, 0, "<stdin>", options);
|
|
|
|
if (res < 0)
|
|
|
|
goto end;
|
|
|
|
errs |= res;
|
2016-05-24 08:11:24 +00:00
|
|
|
read_stdin = 0;
|
|
|
|
continue;
|
|
|
|
} else if (0 < state->prefix_length)
|
|
|
|
arg = prefix_filename(state->prefix,
|
|
|
|
state->prefix_length,
|
|
|
|
arg);
|
|
|
|
|
|
|
|
fd = open(arg, O_RDONLY);
|
2016-08-08 21:03:11 +00:00
|
|
|
if (fd < 0) {
|
|
|
|
error(_("can't open patch '%s': %s"), arg, strerror(errno));
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2016-05-24 08:11:24 +00:00
|
|
|
read_stdin = 0;
|
|
|
|
set_default_whitespace_mode(state);
|
2016-08-08 21:03:00 +00:00
|
|
|
res = apply_patch(state, fd, arg, options);
|
2016-08-08 21:03:11 +00:00
|
|
|
close(fd);
|
2016-08-08 21:03:00 +00:00
|
|
|
if (res < 0)
|
|
|
|
goto end;
|
|
|
|
errs |= res;
|
2016-05-24 08:11:24 +00:00
|
|
|
}
|
|
|
|
set_default_whitespace_mode(state);
|
2016-08-08 21:03:00 +00:00
|
|
|
if (read_stdin) {
|
|
|
|
res = apply_patch(state, 0, "<stdin>", options);
|
|
|
|
if (res < 0)
|
|
|
|
goto end;
|
|
|
|
errs |= res;
|
|
|
|
}
|
2016-05-24 08:11:24 +00:00
|
|
|
|
|
|
|
if (state->whitespace_error) {
|
|
|
|
if (state->squelch_whitespace_errors &&
|
|
|
|
state->squelch_whitespace_errors < state->whitespace_error) {
|
|
|
|
int squelched =
|
|
|
|
state->whitespace_error - state->squelch_whitespace_errors;
|
|
|
|
warning(Q_("squelched %d whitespace error",
|
|
|
|
"squelched %d whitespace errors",
|
|
|
|
squelched),
|
|
|
|
squelched);
|
|
|
|
}
|
2016-08-08 21:03:11 +00:00
|
|
|
if (state->ws_error_action == die_on_ws_error) {
|
|
|
|
error(Q_("%d line adds whitespace errors.",
|
|
|
|
"%d lines add whitespace errors.",
|
|
|
|
state->whitespace_error),
|
|
|
|
state->whitespace_error);
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2016-05-24 08:11:24 +00:00
|
|
|
if (state->applied_after_fixing_ws && state->apply)
|
|
|
|
warning("%d line%s applied after"
|
|
|
|
" fixing whitespace errors.",
|
|
|
|
state->applied_after_fixing_ws,
|
|
|
|
state->applied_after_fixing_ws == 1 ? "" : "s");
|
|
|
|
else if (state->whitespace_error)
|
|
|
|
warning(Q_("%d line adds whitespace errors.",
|
|
|
|
"%d lines add whitespace errors.",
|
|
|
|
state->whitespace_error),
|
|
|
|
state->whitespace_error);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (state->update_index) {
|
2016-08-08 21:03:11 +00:00
|
|
|
res = write_locked_index(&the_index, state->lock_file, COMMIT_LOCK);
|
|
|
|
if (res) {
|
|
|
|
error(_("Unable to write new index file"));
|
|
|
|
res = -128;
|
|
|
|
goto end;
|
|
|
|
}
|
2016-06-03 16:58:52 +00:00
|
|
|
state->newfd = -1;
|
2016-05-24 08:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return !!errs;
|
2016-08-08 21:03:00 +00:00
|
|
|
|
|
|
|
end:
|
2016-08-08 21:03:11 +00:00
|
|
|
if (state->newfd >= 0) {
|
|
|
|
rollback_lock_file(state->lock_file);
|
|
|
|
state->newfd = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (res == -1 ? 1 : 128);
|
2016-05-24 08:11:24 +00:00
|
|
|
}
|
2006-06-24 20:10:11 +00:00
|
|
|
|
2016-05-24 08:11:24 +00:00
|
|
|
int cmd_apply(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2008-12-27 23:03:57 +00:00
|
|
|
int force_apply = 0;
|
2016-05-11 13:16:17 +00:00
|
|
|
int options = 0;
|
2016-05-24 08:11:24 +00:00
|
|
|
int ret;
|
2016-05-11 13:16:19 +00:00
|
|
|
struct apply_state state;
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2008-12-27 23:03:57 +00:00
|
|
|
struct option builtin_apply_options[] = {
|
2016-05-24 08:11:07 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "exclude", &state, N_("path"),
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("don't apply changes matching the given path"),
|
2016-09-04 20:18:20 +00:00
|
|
|
0, apply_option_parse_exclude },
|
2016-05-24 08:11:07 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "include", &state, N_("path"),
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("apply changes matching the given path"),
|
2016-09-04 20:18:20 +00:00
|
|
|
0, apply_option_parse_include },
|
2016-05-24 08:11:09 +00:00
|
|
|
{ OPTION_CALLBACK, 'p', NULL, &state, N_("num"),
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("remove <num> leading slashes from traditional diff paths"),
|
2016-09-04 20:18:20 +00:00
|
|
|
0, apply_option_parse_p },
|
2016-05-24 08:11:00 +00:00
|
|
|
OPT_BOOL(0, "no-add", &state.no_add,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("ignore additions made by the patch")),
|
2016-05-24 08:10:56 +00:00
|
|
|
OPT_BOOL(0, "stat", &state.diffstat,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("instead of applying the patch, output diffstat for the input")),
|
2011-09-28 17:47:54 +00:00
|
|
|
OPT_NOOP_NOARG(0, "allow-binary-replacement"),
|
|
|
|
OPT_NOOP_NOARG(0, "binary"),
|
2016-05-24 08:10:57 +00:00
|
|
|
OPT_BOOL(0, "numstat", &state.numstat,
|
2012-08-20 12:32:55 +00:00
|
|
|
N_("show number of added and deleted lines in decimal notation")),
|
2016-05-24 08:10:58 +00:00
|
|
|
OPT_BOOL(0, "summary", &state.summary,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("instead of applying the patch, output a summary for the input")),
|
2016-05-24 08:10:48 +00:00
|
|
|
OPT_BOOL(0, "check", &state.check,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("instead of applying the patch, see if the patch is applicable")),
|
2016-05-24 08:10:49 +00:00
|
|
|
OPT_BOOL(0, "index", &state.check_index,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("make sure the patch is applicable to the current index")),
|
2016-05-24 08:10:55 +00:00
|
|
|
OPT_BOOL(0, "cached", &state.cached,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("apply a patch without touching the working tree")),
|
2016-05-24 08:11:01 +00:00
|
|
|
OPT_BOOL(0, "unsafe-paths", &state.unsafe_paths,
|
2015-01-29 23:35:24 +00:00
|
|
|
N_("accept a patch that touches outside the working area")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "apply", &force_apply,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("also apply the patch (use with --stat/--summary/--check)")),
|
2016-05-24 08:10:59 +00:00
|
|
|
OPT_BOOL('3', "3way", &state.threeway,
|
2012-07-16 04:38:51 +00:00
|
|
|
N_( "attempt three-way merge if a patch does not apply")),
|
2016-05-24 08:11:03 +00:00
|
|
|
OPT_FILENAME(0, "build-fake-ancestor", &state.fake_ancestor,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("build a temporary index based on embedded index information")),
|
2016-01-31 11:35:46 +00:00
|
|
|
/* Think twice before adding "--nul" synonym to this */
|
2016-05-24 08:11:02 +00:00
|
|
|
OPT_SET_INT('z', NULL, &state.line_termination,
|
2016-01-31 11:35:46 +00:00
|
|
|
N_("paths are separated with NUL character"), '\0'),
|
2016-05-24 08:11:04 +00:00
|
|
|
OPT_INTEGER('C', NULL, &state.p_context,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("ensure at least <n> lines of context match")),
|
2016-05-24 08:11:13 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "whitespace", &state, N_("action"),
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("detect new or modified lines that have whitespace errors"),
|
2016-09-04 20:18:20 +00:00
|
|
|
0, apply_option_parse_whitespace },
|
2016-05-24 08:11:18 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "ignore-space-change", &state, NULL,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("ignore changes in whitespace when finding context"),
|
2016-09-04 20:18:20 +00:00
|
|
|
PARSE_OPT_NOARG, apply_option_parse_space_change },
|
2016-05-24 08:11:18 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "ignore-whitespace", &state, NULL,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("ignore changes in whitespace when finding context"),
|
2016-09-04 20:18:20 +00:00
|
|
|
PARSE_OPT_NOARG, apply_option_parse_space_change },
|
2016-05-24 08:10:50 +00:00
|
|
|
OPT_BOOL('R', "reverse", &state.apply_in_reverse,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("apply the patch in reverse")),
|
2016-05-24 08:10:47 +00:00
|
|
|
OPT_BOOL(0, "unidiff-zero", &state.unidiff_zero,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("don't expect at least one line of context")),
|
2016-05-24 08:10:51 +00:00
|
|
|
OPT_BOOL(0, "reject", &state.apply_with_reject,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("leave the rejected hunks in corresponding *.rej files")),
|
2016-05-24 08:10:54 +00:00
|
|
|
OPT_BOOL(0, "allow-overlap", &state.allow_overlap,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("allow overlapping hunks")),
|
2016-05-24 08:10:52 +00:00
|
|
|
OPT__VERBOSE(&state.apply_verbosely, N_("be verbose")),
|
2008-12-27 23:03:57 +00:00
|
|
|
OPT_BIT(0, "inaccurate-eof", &options,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("tolerate incorrectly detected missing new-line at the end of file"),
|
2008-12-27 23:03:57 +00:00
|
|
|
INACCURATE_EOF),
|
|
|
|
OPT_BIT(0, "recount", &options,
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("do not trust the line counts in the hunk headers"),
|
2008-12-27 23:03:57 +00:00
|
|
|
RECOUNT),
|
2016-05-24 08:11:11 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "directory", &state, N_("root"),
|
2012-05-06 14:23:52 +00:00
|
|
|
N_("prepend <root> to all filenames"),
|
2016-09-04 20:18:20 +00:00
|
|
|
0, apply_option_parse_directory },
|
2008-12-27 23:03:57 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
2016-08-08 21:03:08 +00:00
|
|
|
if (init_apply_state(&state, prefix, &lock_file))
|
|
|
|
exit(128);
|
2007-02-17 20:37:25 +00:00
|
|
|
|
2016-05-11 13:16:19 +00:00
|
|
|
argc = parse_options(argc, argv, state.prefix, builtin_apply_options,
|
2008-12-27 23:03:57 +00:00
|
|
|
apply_usage, 0);
|
2009-05-23 18:53:11 +00:00
|
|
|
|
2016-08-08 21:03:09 +00:00
|
|
|
if (check_apply_state(&state, force_apply))
|
|
|
|
exit(128);
|
2015-01-29 23:35:24 +00:00
|
|
|
|
2016-05-24 08:11:24 +00:00
|
|
|
ret = apply_all_patches(&state, argc, argv, options);
|
2005-05-23 17:52:17 +00:00
|
|
|
|
2016-05-24 08:10:46 +00:00
|
|
|
clear_apply_state(&state);
|
2005-11-26 07:14:15 +00:00
|
|
|
|
2016-05-24 08:11:24 +00:00
|
|
|
return ret;
|
2005-05-23 17:52:17 +00:00
|
|
|
}
|