Bug: fatal: patch fragment without header at line

Bug: fatal: patch fragment without header at line

[tuxdna]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

Git version: git-1.7.7.6-1.fc16.x86_64

I am getting an error with a patch that I am applying to a git repository.
I have created a test case for this issue that I am facing.

$ git apply --check 0001-modified-README.patch
fatal: patch fragment without header at line 7: @@ -635,9 +635,7 @@
some_function()

Clearly line 7 appears to be a patch but it isn't. It is the part of
email body or the patch context.
To my understanding, the patch should always be identified whenever
the patch block starts
with a "diff --git", which is line 21 as below:

     1	From aa3acc563af0422e6a9f4afc432b7fabdf845d81 Mon Sep 17 00:00:00 2001
     2	From: Saleem Ansari <tuxdna@gmail.com>
     3	Date: Mon, 16 Jul 2012 17:42:58 +0530
     4	Subject: [PATCH] modified README
     5	
     6	
     7	@@ -635,9 +635,7 @@ some_function()
     8	
     9	
    10	-       # a comment here
    11	+       not a comment
    12	
    13	
    14	
    15	thats all folks
    16	
    17	---
    18	 README |    1 +
    19	 1 files changed, 1 insertions(+), 0 deletions(-)
    20	
    21	diff --git a/README b/README
    22	index ce01362..d294257 100644
    23	--- a/README
    24	+++ b/README
    25	@@ -1 +1,2 @@
    26	 hello
    27	+this is a readme
    28	--
    29	1.7.7.6
    30	

Apart from changing the patch itself, how else can I work-around this problem?

Steps to create and verify the testcase:

# Create a temporary directory
mkdir /tmp/bug
cd /tmp/bug
git init .
echo "hello" > README
git commit -m "Initial commit"

# create a test branch for verification later
git checkout -b test

# make changes into a different branch
git checkout -b bugger
echo "this is a readme" > README
git commit -m "modified README"
git format-patch HEAD^ # this will generate 0001-modified-README.patch
# Now inside the patch email body add some random patch which should break
# or download the attachment ( 0001-modified-README.patch )

/tuxdna

[-- Attachment #2: 0001-modified-README.patch --]
[-- Type: application/octet-stream, Size: 497 bytes --]

From aa3acc563af0422e6a9f4afc432b7fabdf845d81 Mon Sep 17 00:00:00 2001
From: Saleem Ansari <tuxdna@gmail.com>
Date: Mon, 16 Jul 2012 17:42:58 +0530
Subject: [PATCH] modified README


@@ -635,9 +635,7 @@ some_function()


-       # a comment here
+       not a comment



thats all folks

---
 README |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/README b/README
index ce01362..d294257 100644
--- a/README
+++ b/README
@@ -1 +1,2 @@
 hello
+this is a readme
-- 
1.7.7.6

Re: Bug: fatal: patch fragment without header at line

[Junio C Hamano]

tuxdna <tuxdna@gmail.com> writes:

> Git version: git-1.7.7.6-1.fc16.x86_64
>
> I am getting an error with a patch that I am applying to a git repository.
> I have created a test case for this issue that I am facing.
>
> $ git apply --check 0001-modified-README.patch
> fatal: patch fragment without header at line 7: @@ -635,9 +635,7 @@
> some_function()
>
> Clearly line 7 appears to be a patch but it isn't. It is the part of
> email body or the patch context.

Yes, but the error detection needs to stay for a more common case in
which the user corrupted the patch by breaking or removing the diff
header.

If you want to quote a patch fragment in your log message, it is
common to indent the part (without removing the "diff" header) which
also has the benefit of making it stand out in the textual
description, e.g. here is a sample patch fragment

    diff --git a/README b/README
    index ce01362..d294257 100644
    --- a/README
    +++ b/README
    @@ -1 +1,2 @@
     hello
    +this is a readme

and here comes a paragraph in the log message that can be made more
understandable by having such a patch fragment.

Re: Bug: fatal: patch fragment without header at line

[Jeff King]

On Mon, Jul 16, 2012 at 07:06:51PM +0530, tuxdna wrote:

> Git version: git-1.7.7.6-1.fc16.x86_64
> 
> I am getting an error with a patch that I am applying to a git repository.
> I have created a test case for this issue that I am facing.
> 
> $ git apply --check 0001-modified-README.patch
> fatal: patch fragment without header at line 7: @@ -635,9 +635,7 @@
> some_function()
> 
> Clearly line 7 appears to be a patch but it isn't. It is the part of
> email body or the patch context.
> To my understanding, the patch should always be identified whenever
> the patch block starts
> with a "diff --git", which is line 21 as below:

It is identified properly when you use "git am" to apply your patch. It
will use "git mailinfo" to split on the "---" and feed only the bottom
half to "git apply". But as a low-level tool, "git apply" looks for a
patch immediately, and does not know anything about the "---" line. It
is correct to diagnose a possibly broken patch.

> Apart from changing the patch itself, how else can I work-around this problem?

Run "git am 0001-modified-README.patch" to parse it correctly. If for
some reason you really do not want to make a commit (e.g., you are going
to squash-apply a bunch of patches together), then either:

  1. Don't use format-patch to generate the patch. Use "git diff-tree",
     which will omit the commit message (which "git apply" would just
     inore anyway).

  2. Use "git mailinfo" to split the patch out of the email format
     generated by format-patch, and then "git apply" the result.

-Peff