Normalmente, você pode contornar isso usando a -l option :
use the -l or --ignore-whitespace option, which makes patch compare blank characters (i.e. spaces and tabs) loosely so that any nonempty sequence of blanks in the patch file matches any nonempty sequence of blanks in the input files
Este é um recurso padrão (veja a descrição patch POSIX ).
No entanto, o OP alterou a questão para comentar sobre Como as conversões de término de linha funcionam com o git core.autocrlf entre diferentes sistemas operacionais , e adicionamos um exemplo sugerindo que o problema é visto em arquivos no Windows (em contraste com o exemplo do estilo Unix). Enquanto patch tenta acomodar incompatibilidades entre as terminações de linha CRLF e LF, ele tem um viés para presumir que o último é usado. Se o arquivo de patch tivesse terminações CRLF, enquanto os arquivos a serem corrigidos não, ele se recuperaria como neste log de exemplo:
(Stripping trailing CRs from patch.)
patching file xterm.log.html
(Stripping trailing CRs from patch.)
patching file xterm.man
(Stripping trailing CRs from patch.)
patching file xtermcfg.hin
Verificando o código-fonte, na função similar , GNU patch trata os espaços em branco como space e Tab , com algum tratamento especial de acordo com as linhas que têm um LF à direita. CR não é mencionado. Ele presta atenção em check_line_endings , mas usa isso informações apenas como parte de uma mensagem para ajudar a diagnosticar uma rejeição. Ele remove os CRs em pget_line a menos que --binary opção é dada.
O patch GNU não tem uma opção para dizer a ele para transformar um patch com finais LF em CRLF para aplicar em arquivos cujos fins de linha são CRLF. Para usá-lo de forma confiável para este caso, as opções são
- converte todos os arquivos para usar finais de LF ou
- converta todos os arquivos para usar as terminações CRLF e adicione a opção
--binary .