Re: Bug in 'git am' when applying a broken patch
- From
Greg KH <gregkh@linuxfoundation.org>
- Date
- Jun 2, 2015, 01:26 UTC
- Message-ID
- <20150602012614.GD23370@kroah.com>
- In-Reply-To
- <xmqq8uc35gap.fsf@gitster.dls.corp.google.com>
On Mon, Jun 01, 2015 at 01:23:26PM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> Eric Sunshine <sunshine@sunshineco.com> writes: > > > s/enw/new/ > > Heh, thanks; I wasn't planning to commit this one yet, but why not.
Well, it's not good to apply a commit with no actual commit. That never a good thing, and was the thing that really confused me about this issue.
Show 36 quoted lines
> Here is with an updated log message and a test. > > -- >8 -- > Subject: [PATCH] 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 input does not have a good way for us to diagnose > it as a corrupt patch. We just read two context lines and discard > the remainder as cruft, which we must do in order to ignore the > e-mail footer. Notice that the patch does not change anything and > signal an error. > > Note that this fix will not help if the hand-edited hunk header were > "@@ -660,3, +660,2" to include the removal. We would just remove > the old text without adding the new one, and treat "+ some new text" > and everything after that line as trailing cruft. So it is dubious > that this patch alone would help very much in practice, but it may > be better than nothing. > > Signed-off-by: Junio C Hamano <gitster@pobox.com> > --- > builtin/apply.c | 3 +++ > t/t4136-apply-check.sh | 13 +++++++++++++ > 2 files changed, 16 insertions(+)
Looks good to me, thanks for fixing this, much appreciated.
greg k-h