È necessario passare la flag --keep-cr
a git am
. È spiacevole, ma a causa degli standard concorrenti (flusso di lavoro della posta elettronica rispetto al locale), non c'è davvero molta scelta.
Si consiglia di provare anche la creazione di un file .gitattributes
. Cercando di ricreare il tuo problema, sono riuscito a far funzionare le cose quando ho specificato che il file richiedeva CRLF. Nota, senza prima normalizzare i file, ha mostrato l'intero file come modificato. Io uso un comunemente .gitattributes
con questo:
.gitattributes export-ignore
.gitignore export-ignore
*.txt text
*.C text trailing-space space-before-tab -indent-with-non-tab
*.rst text trailing-space space-before-tab -indent-with-non-tab
*.clj text trailing-space space-before-tab -indent-with-non-tab
*.c text diff=cpp trailing-space space-before-tab -indent-with-non-tab
*.cpp text diff=cpp trailing-space space-before-tab -indent-with-non-tab
*.h text diff=cpp trailing-space space-before-tab -indent-with-non-tab
*.hpp text diff=cpp trailing-space space-before-tab -indent-with-non-tab
*.py text diff=python trailing-space space-before-tab -indent-with-non-tab
*.tex text diff=tex
*.java text diff=java trailing-space space-before-tab -indent-with-non-tab
*.pl text diff=perl trailing-space space-before-tab -indent-with-non-tab
*.php text diff=php
*.rb text diff=ruby trailing-space space-before-tab -indent-with-non-tab
*.vcproj eol=crlf
*.dsp eol=crlf
*.dsw eol=crlf
*.sh eol=lf
*.jpg binary
*.png binary
*.gif binary
*.tiff binary
Avrai voglia di normalizzare la vostra linea che termina secondo il gitattributes man page. Un altro utente SO ha finito per disattivare core.autocrlf
as well per ottenere commit e patch puliti.
cercando di riprodurre il bug
$ git init repo
Initialized empty Git repository in c:/tmp/git-eol/repo/.git/
$ cd repo
$ git config --local core.autocrlf false
$ vim foo.txt
$ git add foo.txt
$ git commit -m "Add foo."
[master (root-commit) 3903abd] Add foo.
1 file changed, 3 insertions(+)
create mode 100644 foo.txt
$ vim foo.txt
$ git st
## master
M foo.txt
$ git commit -m "Add more foo." -a
[master 03e991a] Add more foo.
1 file changed, 2 insertions(+)
$ git format-patch HEAD~1
0001-Add-more-foo.patch
$ vim 0001-Add-more-foo.patch
Guardando il file di patch che è stato prodotto, vedo questo:
Come si può vedere, i ritorni a capo (^M
s) sono stati tenuti nella patch. Questo è con core.autocrlf=false
. Proseguendo, vedo:
$ git reset --hard HEAD~1
HEAD is now at 3903abd Add foo.
$ git am 0001-Add-more-foo.patch
Applying: Add more foo.
error: patch failed: foo.txt:1
error: foo.txt: patch does not apply
Patch failed at 0001 Add more foo.
The copy of the patch that failed is found in:
c:/tmp/git-eol/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
$ git am --abort
Quindi la patch non si applica bene out-of-the-box. L'utilizzo di --keep-cr
era come previsto:
$ git am --keep-cr 0001-Add-more-foo.patch
Applying: Add more foo.
$
OK.Così proviamo questo con core.autocrlf=true
(in un repository diverso):
# Removed the initial commands...
$ git format-patch HEAD~1
0001-Add-more-foo.patch
$ git reset --hard HEAD~1
HEAD is now at 525b5aa Initial commit.
$ git am 0001-Add-more-foo.patch
Applying: Add more foo.
$ git config --get core.autocrlf
true
La patch in questo caso ha avuto terminazioni LF ovunque.
Puoi mostrarci di più su quali comandi stai eseguendo? Su quale sistema operativo stai funzionando? Qual è il contenuto di .gitattributes? – jszakmeister