All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Git List <git@vger.kernel.org>,
	Gaston Gonzalez <gascoar@gmail.com>
Subject: Re: Bug in 'git am' when applying a broken patch
Date: Fri, 26 Jun 2015 13:58:21 -0700	[thread overview]
Message-ID: <xmqq7fqqtceq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAGZ79kYbyTOeEvJBPqWOX8fxbB637N5aV3Q=yENQXu4v9FzBPQ@mail.gmail.com> (Stefan Beller's message of "Fri, 26 Jun 2015 12:49:46 -0700")

Stefan Beller <sbeller@google.com> writes:

> In the hunk header we can learn about the
> expected lines to read for this hunk and after the hunk we only have
> 3 possible lines:
>
>   * it's the next hunk, then the line starts with @@

This is true.

>   * it's a new file, so the line starts with "diff --git"

This is true with s/--git//.

>   * it's the end of the patch, so the line is "--\n" and the line there after
>     is version number as git describe puts (not sure we want to test on that)

This is not true in general, as we do not want to limit "git apply"
to only what "git diff" produces.  You can write anything after a
patch and that is still a valid patch.  And that anything could be a
line that begins with '-', ' ' and '+'; as long as the line numbers
in the hunk header are correct, we'd ignore it.

So as you said, the change you are responding to is "better than
nothing", and would only help when you truncate the patch (or break
the numbers), but does not protect against arbitrary breakage.

One thing we _could_ do is after seeing the end of a message
(i.e. we did not see "@@" that signals there are more hunks in the
current patch, and we did not see "diff " that signals there are
more patches), we keep scanning and declare breakage if we see lines
that begin with something that looks like a hunk "@@ ... @@".

      reply	other threads:[~2015-06-26 21:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01  0:17 Bug in 'git am' when applying a broken patch Greg KH
2015-06-01  1:54 ` Greg KH
2015-06-01 12:09   ` Christian Couder
2015-06-01 18:31 ` Junio C Hamano
2015-06-01 18:58   ` Junio C Hamano
2015-06-01 20:09     ` Eric Sunshine
2015-06-01 20:23       ` Junio C Hamano
2015-06-02  1:26         ` Greg KH
2015-06-26 19:49         ` Stefan Beller
2015-06-26 20:58           ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7fqqtceq.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=gascoar@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=sbeller@google.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.