Flag empty patches as errors

Flag empty patches as errors

[Linus Torvalds]

A patch that contains no actual diff, and that doesn't change any 
meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't 
just accept it.

This caused a corrupted patch to be silently applied as an empty change in 
the kernel, because the corruption ended up making the patch look empty.

An example of such a patch is one that contains the patch header, but 
where the initial fragment header (the "@@ -nr,.." line) is missing, 
causing us to not parse any fragments.

The real "patch" program will also flag such patches as bad, with the 
message

	patch: **** Only garbage was found in the patch input.

and we should do likewise.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -723,6 +723,16 @@ static int parse_single_patch(char *line
 	return offset;
 }
 
+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);
+}
+
 static int parse_chunk(char *buffer, unsigned long size, struct patch *patch)
 {
 	int hdrsize, patchsize;
@@ -733,6 +743,9 @@ static int parse_chunk(char *buffer, uns
 
 	patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
 
+	if (!patchsize && !metadata_changes(patch))
+		die("patch with only garbage at line %d", linenr);
+
 	return offset + hdrsize + patchsize;
 }
 

Re: Flag empty patches as errors

[Junio C Hamano]

Thanks.  Applied.

Packing on kernel.org

[Martin Coxall]

Was there an cron process or kernel.org that should be repacking the 
public repositories periodically?

The git/cogito/sparse/linux-2.6 repositories all now have several 
thousand unpacked objects a piece, and it takes so long to do an http 
clone it's not even funny.

Martin

Re: Packing on kernel.org

[H. Peter Anvin]

Martin Coxall wrote:
> Was there an cron process or kernel.org that should be repacking the 
> public repositories periodically?

No, too many people complained.

> The git/cogito/sparse/linux-2.6 repositories all now have several 
> thousand unpacked objects a piece, and it takes so long to do an http 
> clone it's not even funny.

HARP: Please pack your repositories periodically.  PLEASE.  It matters 
especially now when kernel.org is down one server.

If your username is high on this list, it's imperative that you pack 
your trees:

brodo                 197469
wim                   184343
marcelo                68442
jgarzik                59860
lm                     39680
mpm                    38995
pavel                  37624
lenb                   36406
hch                    34037
davem                  27671
jejb                   23553
willy                  21626
pasky                  17019
sfrench                15912
smurf                  15236
acme                   12504
torvalds                8834
aegl                    7369
ericvh                  6750
roland                  6296
airlied                 6053
chrisw                  5619
axboe                   5221
dwmw2                   4101
gregkh                  3659
dtor                    3537
hpa                     3350
paulus                  2074
perex                   1999
bart                    1955
cvaroqui                1537
kay                     1250
junio                   1119
sam                     1073
kkeil                   1050

	-hpa