14

I created a diff file by a command:

git --no-pager diff --no-index --stat pathA pathB >\diff.log

Nextly, I executed a command:

git apply --index --ignore-space-change --ignore-whitespace \diff.log

During the execution I encountered an error:

error: git diff header lacks filename information when removing 1 leading pathname component (line 2138)

Line 2138 leads to:

2136 diff --git a/C:\Temp\right_tmp5D66/file.cpp b/file.cpp

2137 new file mode 100644

2138 index 0000000000000000000000000000000000000000..e69de...

2139 diff --git ......

I have tried a command "git apply --reject ..." but it also didn't work. I also added config which ignores chmod changes (git config core.fileMode false) and nothing was changed.

Community
  • 1
  • 1
krawat10
  • 181
  • 1
  • 10
  • 1
    Try changing `C:\Temp\right_tmp5D66/file.cpp` to `file.cpp` in the patch. Git is probably getting confused by the `C:` part (and Git in general prefers the forward-slash syntax). – torek Jan 02 '19 at 19:47

6 Answers6

10

Most probably because you have this setting in the git config (~/.gitconfg):

[diff]
  noprefix = true

So, you can remove it or change to false:

git config --global diff.noprefix false

milushov
  • 710
  • 11
  • 28
  • 3
    Is there anyway to make `git apply` work while also keeping this `noprefix` setting? – Amandasaurus Jan 27 '21 at 11:44
  • I've run into a similar problem using `git format-patch` and `git am`. I do have `noprefix = true`, but removing it didn't fix the problem. – Keith Thompson Jan 07 '22 at 19:39
  • Hmm. I tried again, and it appears that setting `noprefix = false` does fix the problem. I'm not sure why I thought it didn't; likely user error on my part. – Keith Thompson Jan 07 '22 at 23:51
2

you can try this.

patch -p0 < filename

This patch command reads a source file's instructions on how to change a file, then applies the changes. The source file contains difference listings (or diff listings) and one or more sets of diff command output, like called hunks.

The patch command skips any leading text in a patch file, applies the actual diff listing, and skips any trailing text. Thus, you could use as a patch file or message that includes a diff listing, and the patch command would still work. In such a case, if the entire diff listing is indented by a consistent amount, the patch command will also adjust for that spacing.

  • p0 leaves the entire path name unmodified.
vignesh
  • 21
  • 2
1

I got

error: git diff header lacks filename information when removing 1 leading pathname component (line 5)

on the following patch, generated using svn diff --git (svn, version 1.14.1 (r1886195) running on Debian) and that I tried to git apply (git version 2.30.2 running on Debian):

Index: essai/essai.txt
===================================================================
diff --git a/essai/essai.txt b/essai/essai.txt
new file mode 100644

What this patch does is creating a new empty file named essai/essai.txt.

The problem is that on Windows svn adds a CRLF line ending on the diff --git line. This cause trouble in git.

Try using Linux, or submit a patch to git or svn, or hack the patches generated with svn diff --git.

Gabriel Devillers
  • 3,155
  • 2
  • 30
  • 53
  • Other suggestion: use `--diff-cmd` and write a custom handler (I did that using `git` to do the diffing, resulting in patches being easier to use in git). – Gabriel Devillers Apr 02 '23 at 21:10
0

This behaviour is probably due to the different filenames. git apply cannot deduce if a rename is involved and rejects the patch.

If you want to apply a binary patch both file-names need to be the same.

A patch following this format should work:

diff --git a/a_path/binary_file.img b/a_path/binary_file.img
index …
GIT binary patch
delta …
…data…

This will probably fail:

diff --git a/a_path/binary_file.img b/a_path/renamed_binary_file.img
index …
GIT binary patch
delta …
…data…

So, if you're using git diff --no-index you will have to change the filename(s) in the patch manually. Only then will git apply know on what to apply your patch.

See also this comment from Linus Torvalds:

And that, btw, is no longer a bug, I think. It's impossible to know whethe the user meant for the patch to be a rename or not. And as such, refusing to apply it because you don't know what name you should use is probably exactly the right thing to do!

iolsmit
  • 383
  • 2
  • 13
0

Make sure your current working directory is correct.

devhl
  • 111
  • 1
  • 9
0

For me this error happened on Windows and was caused by the patch file using CRLF line endings. Changing the line endings to LF made the patch apply without errors.

Frederik
  • 467
  • 6
  • 16