Re: Bug in 'git am' when applying a broken patch
On Mon, Jun 1, 2015 at 2:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
> Subject: apply: reject a hunk that does not do anything
>
> A hunk like this in a hand-edited patch without correctly adjusting
> the line counts:
>
> @@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
> auth = (struct ieee80211_authentication *)
> skb_put(skb, sizeof(struct ieee80211_authentication));
> - some old text
> + some new text
> --
> 2.1.0
>
> dev mailing list
>
> at the end of the patch does not have a good way for us to diagnose
> it as corrupt patch. We just read two lines and discard the remainder
> as cruft, which we must do in order to ignore the e-mail footer.
>
> If the hand-edited hunk header were "@@ -660,3, +660,2", this fix
> will not help---we would just remove the old text without adding the
> enw one, and treat "+ some new text" and everything after that line
Show 23 quoted lines
> as trailing cruft. So it is dubious that this patch would help very
> much in practice, but it is better than nothing ;-)
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin/apply.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 146be97..54aba4e 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -1638,6 +1638,9 @@ static int parse_fragment(const char *line, unsigned long size,
> }
> if (oldlines || newlines)
> return -1;
> + if (!deleted && !added)
> + return -1;
> +
> fragment->leading = leading;
> fragment->trailing = trailing;
>
> --