Re: Bug in 'git am' when applying a broken patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> 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 "@@ ... @@".

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]