More "git-apply" safety fixes

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>
----

If you already applied the first hunk, just ignore that part, and apply 
the second one that adds the test for oldlines/newlines being zero after 
the patch.

Neither of these two changes should matter for a well-formed patch, but 
it's definitely the right thing to do.

diff --git a/apply.c b/apply.c
index 2da225a..c50b3a6 100644
--- a/apply.c
+++ b/apply.c

@@ -693,7 +693,7 @@ static int parse_range(const char *line,
 	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, un
 			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.