# Flag empty patches as errors 4 messages from 2005-10-01 to 2005-10-01. Participants: Linus Torvalds, Junio C Hamano, Martin Coxall, H. Peter Anvin. Thread: https://gitlist.dev/t/1990 ## Linus Torvalds, 2005-10-01 06:25 Subject: Flag empty patches as errors Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0509302320560.3378%40g5.osdl.org ``` 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 --- 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; } ``` ## Junio C Hamano, 2005-10-01 07:15 Subject: Re: Flag empty patches as errors Message-ID: <7v3bnlaes7.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bnlaes7.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Thanks. Applied. ``` ## Martin Coxall, 2005-10-01 09:02 Subject: Packing on kernel.org Message-ID: <068ea79fc648433faa44a6d4cc287614@cream.org> URL: https://gitlist.dev/e/068ea79fc648433faa44a6d4cc287614%40cream.org In-Reply-To: ``` 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 ``` ## H. Peter Anvin, 2005-10-01 14:21 Subject: Re: Packing on kernel.org Message-ID: <433E9B73.3040807@zytor.com> URL: https://gitlist.dev/e/433E9B73.3040807%40zytor.com In-Reply-To: <068ea79fc648433faa44a6d4cc287614@cream.org> ``` 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 ```