undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

git-apply: safety fixes

Browse Source 
This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.

Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.

So make git-apply refuse to look at a patch fragment that ends early.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Linus Torvalds 2006-03-25 13:28:28 -08:00 committed by Junio C Hamano
parent 6a1640ffc6
commit c150462824
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
apply.c
View File

@ -693,7 +693,7 @@ static int parse_range(const char *line, int len, int offset, const char *expect
line += digits;
len -= digits;
*p2 = *p1;
*p2 = 1;
if (*line == ',') {
digits = parse_num(line+1, p2);
if (!digits)
@ -901,6 +901,8 @@ static int parse_fragment(char *line, unsigned long size, struct patch *patch, s
break;
}
}
if (oldlines || newlines)
return -1;
/* If a fragment ends with an incomplete line, we failed to include
* it in the above loop because we hit oldlines == newlines == 0
* before seeing it.