From: Eric Sunshine Date: Mon, 01 Jun 2015 20:09:55 GMT Subject: Re: Bug in 'git am' when applying a broken patch Message-ID: In-Reply-To: On Mon, Jun 1, 2015 at 2:58 PM, Junio C Hamano wrote: > 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 s/enw/new/ > 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 > --- > 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; > > --