git substituindo LF por CRLF

Executando o git em uma máquina Windows XP, usando o bash. Eu exportei meu projeto do SVN e depois clonei um repositório vazio.

Em seguida, colei a exportação no diretório de repositórios vazios e fiz um:

git add -A

Eu recebi uma lista de mensagens dizendo:

LF será substituído por CRLF

Quais são as ramificações dessa conversão? Esta é uma solução .NET no Visual Studio.

Essas mensagens são devido ao valor padrão incorreto core.autocrlfno Windows.

O conceito de autocrlfé manipular conversões de finais de linha de forma transparente. E faz!

Más notícias : o valor precisa ser configurado manualmente.
Boas notícias : isso deve ser feito apenas UMA vez por instalação do git (por configuração do projeto também é possível).

Como autocrlffunciona :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Aqui crlf= marcador de fim de linha no estilo win, lf= estilo unix (e mac osx).

(pré-osx crnão afetado por nenhuma das três opções acima)

Quando esse aviso aparece (no Windows)

    - autocrlf= truese você possui estilo unix lfem um dos seus arquivos (= RARAMENTE),
    - autocrlf= inputse você possui estilo win crlfem um dos seus arquivos (= quase SEMPRE),
    - autocrlf= false- NUNCA!

O que esse aviso significa

O aviso " LF será substituído pelo CRLF " diz que você (tendo autocrlf= true) perderá o seu LF no estilo unix após o ciclo de confirmação da compra (ele será substituído pelo CRLF no estilo do Windows). O Git não espera que você use LF estilo unix no Windows.

O aviso " CRLF será substituído por LF " diz que você (tendo autocrlf= input) perderá seu CRLF no estilo do Windows após um ciclo de confirmação (ele será substituído pelo LF no estilo unix). Não use inputsob janelas.

Mais uma maneira de mostrar como autocrlffunciona

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

onde x é CRLF (estilo Windows) ou LF (estilo Unix) e setas representam

file to commit -> repository -> checked out file

Como consertar

O valor padrão para core.autocrlfé selecionado durante a instalação do git e armazenado em gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) em todo o sistema . Também há (em cascata na seguinte ordem):

   - gitconfig "global" (por usuário) localizado em ~/.gitconfig, ainda outro
   - gitconfig "global" (por usuário) em $XDG_CONFIG_HOME/git/configou $HOME/.config/git/confige
   - gitconfig "local" (por repo) no .git/configdiretório de trabalho.

Portanto, escreva git config core.autocrlfno diretório de trabalho para verificar o valor atualmente usado e

   - adicionar autocrlf=falseà solução gitconfig do sistema # por sistema
   - git config --global core.autocrlf false            # solução por usuário
   - git config --local core.autocrlf false              # solução por projeto

Avisos
- as git configconfigurações podem ser substituídas pelas gitattributesconfigurações.
- a crlf -> lfconversão ocorre apenas ao adicionar novos arquivos, os crlfarquivos já existentes no repositório não são afetados.

Moral (para Windows):
    - use core.autocrlf= truese você planeja usar este projeto no Unix também (e não deseja configurar seu editor / IDE para usar terminações de linha unix),
    - use core.autocrlf= falsese você planeja usar este projeto apenas no Windows ( ou você configurou seu editor / IDE para usar finais de linha unix),
    - nunca use core.autocrlf=, a inputmenos que você tenha um bom motivo para ( por exemplo, se você estiver usando utilitários unix no Windows ou se tiver problemas com makefiles),

PS O que escolher ao instalar o git para Windows?
Se você não usar nenhum dos seus projetos no Unix, não concorde com a primeira opção padrão. Escolha o terceiro ( Checkout como está, confirme como está ). Você não verá esta mensagem. Sempre.

PPS Minha preferência pessoal é configurar o editor / IDE para usar finais no estilo Unix e definir core.autocrlfcomo false.

O Git possui três modos de como trata as terminações de linha:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Você pode definir o modo de uso, adicionando um parâmetro adicional de trueou falsepara a linha de comando acima.

Se core.autocrlfestiver definido como true, significa que sempre que você adicionar um arquivo ao repositório git que o git considera um arquivo de texto, ele transformará todas as terminações da linha CRLF em apenas LF antes de armazená-lo no commit. Sempre que você desejar git checkout, todos os arquivos de texto terão automaticamente seus finais de linha LF convertidos em finais CRLF. Isso permite o desenvolvimento de um projeto entre plataformas que usam diferentes estilos de final de linha sem comprometer a emissão de muito ruído, porque cada editor altera o estilo de final de linha, pois o estilo de final de linha é sempre consistentemente LF.

O efeito colateral dessa conversão conveniente, e é disso que se trata o aviso, é que, se um arquivo de texto que você criou originalmente tiver terminações LF em vez de CRLF, ele será armazenado com LF como de costume, mas quando marcado mais tarde, ele terá terminações CRLF. Para arquivos de texto normais, isso geralmente é bom. O aviso é "para sua informação" nesse caso, mas, caso o git avalie incorretamente um arquivo binário como um arquivo de texto, é um aviso importante porque o git estaria corrompendo seu arquivo binário.

Se core.autocrlffor definido como falso, nenhuma conversão de final de linha será executada; portanto, os arquivos de texto são verificados como estão. Isso geralmente funciona bem, desde que todos os seus desenvolvedores estejam no Linux ou no Windows. Mas, na minha experiência, continuo tendo arquivos de texto com finais de linha mistos que acabam causando problemas.

Minha preferência pessoal é deixar a configuração ativada, como desenvolvedor do Windows.

Veja http://kernel.org/pub/software/scm/git/docs/git-config.html para obter informações atualizadas que incluem o valor "input".

Se você já fez o check-out do código, os arquivos já estão indexados. Após alterar as configurações do git, diga executando:

git config --global core.autocrlf input 

você deve atualizar os índices com

git rm --cached -r . 

e reescreva o índice git com

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Nota: isso removerá as alterações locais, considere armazená-las antes de fazer isso.

git config core.autocrlf false

O unix2dos e o dos2unix estão disponíveis no Windows com o gitbash. Você pode usar o seguinte comando para executar a conversão UNIX (LF) -> DOS (CRLF). Portanto, você não receberá o aviso.

unix2dos filename

ou

dos2unix -D filename

Mas, não execute este comando em nenhum arquivo CRLF existente; você receberá novas linhas vazias a cada segunda linha.

dos2unix -D filenamenão funcionará com todos os sistemas operacionais. Por favor, verifique este link para compatibilidade.

Se, por algum motivo, você precisar forçar o comando, use --force. Se for inválido, use -f.

Acho que a resposta do @ Basiloungas é próxima, mas desatualizada (pelo menos no Mac).

Abra o arquivo ~ / .gitconfig e defina safecrlfcomo false

[core]
       autocrlf = input
       safecrlf = false

Isso * fará com que ignore o final do caractere de linha aparentemente (funcionou para mim, de qualquer maneira).

Um artigo do GitHub sobre finais de linha é comumente mencionado quando se fala sobre este tópico.

Minha experiência pessoal com o uso da core.autocrlfconfiguração frequentemente recomendada foi muito variada.

Estou usando o Windows com Cygwin, lidando com projetos Windows e UNIX em momentos diferentes. Até meus projetos do Windows às vezes usam bashscripts de shell, que exigem finais de linha UNIX (LF).

Usando a core.autocrlfconfiguração recomendada do GitHub para Windows, se eu verificar um projeto UNIX (que funciona perfeitamente no Cygwin - ou talvez eu esteja contribuindo com um projeto que eu uso no meu servidor Linux), os arquivos de texto são verificados no Windows (CRLF ) terminações de linha, criando problemas.

Basicamente, para um ambiente misto como eu, definir o global core.autocrlfpara qualquer uma das opções não funcionará bem em alguns casos. Essa opção pode ser definida em uma configuração git local (repositório), mas mesmo isso não seria suficiente para um projeto que contém itens relacionados ao Windows e ao UNIX (por exemplo, eu tenho um projeto do Windows com alguns bashscripts utilitários).

A melhor opção que encontrei é criar arquivos .gitattributes por repositório . O artigo do GitHub menciona isso.
Exemplo desse artigo:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

Em um dos repositórios do meu projeto:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

É um pouco mais complicado de configurar, mas faça-o uma vez por projeto, e qualquer colaborador em qualquer sistema operacional não deve ter problemas com as terminações de linha ao trabalhar com este projeto.

No vim, abra o arquivo (por exemplo :e YOURFILEENTER:), depois

:set noendofline binary
:wq

Eu tive esse problema também.

O SVN não faz nenhuma conversão de final de linha; portanto, os arquivos são confirmados com as terminações de linha CRLF intactas. Se você usar git-svn para colocar o projeto no git, as terminações CRLF persistirão no repositório git, que não é o estado que o git espera encontrar - o padrão é ter apenas terminações de linha unix / linux (LF) fez check-in.

Quando você faz o check-out dos arquivos no Windows, a conversão de autocrlf deixa os arquivos intactos (pois eles já possuem as terminações corretas para a plataforma atual); no entanto, o processo que decide se há uma diferença nos arquivos registrados executa a conversão reversa antes da comparação, resultando na comparação do que considera um LF no arquivo com saída com um CRLF inesperado no repositório.

Tanto quanto eu posso ver suas escolhas são:

1. Reimporte seu código para um novo repositório git sem usar o git-svn, isso significa que as terminações de linha são convertidas no commit inicial do git --all
2. Configure autocrlf como false e ignore o fato de que as terminações de linha não estão no estilo preferido do git
3. Verifique seus arquivos com o autocrlf desativado, corrija todas as terminações de linha, verifique tudo novamente e ligue-o novamente.
4. Reescreva o histórico do seu repositório para que o commit original não contenha mais o CRLF que o git não estava esperando. (As advertências usuais sobre reescrever a história se aplicam)

Nota de rodapé: se você escolher a opção nº 2, minha experiência é que algumas das ferramentas auxiliares (rebase, patch etc.) não lidam com arquivos CRLF e você terminará mais cedo ou mais tarde com arquivos com uma mistura de CRLF e LF (linha inconsistente terminações). Não conheço nenhuma maneira de tirar o melhor de ambos.

Removendo o abaixo do arquivo ~ / .gitattributes

* text=auto

impedirá que o git verifique os finais da linha em primeiro lugar.

Deve ler-se:

aviso: ( Se você fizer check-out / ou clonar em outra pasta com o core.autocrlf atual sendotrue ), o LF será substituído pelo CRLF

O arquivo terá suas terminações de linha originais no diretório de trabalho ( atual ).

Esta imagem deve explicar o que isso significa.

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Faça isso em uma consolidação separada ou o git ainda poderá ver arquivos inteiros modificados quando você fizer uma única alteração (dependendo se você alterou a opção autocrlf)

Este realmente funciona. O Git respeitará os finais de linha em projetos de final de linha mista e não o alertará sobre eles.

Eu não sei muito sobre o git no Windows, mas ...

Parece-me que o git está convertendo o formato de retorno para corresponder ao da plataforma em execução (Windows). CRLF é o formato de retorno padrão no Windows, enquanto LF é o formato de retorno padrão para a maioria dos outros sistemas operacionais.

Provavelmente, o formato de retorno será ajustado corretamente quando o código for movido para outro sistema. Também acho que o git é inteligente o suficiente para manter intactos os arquivos binários, em vez de tentar converter LFs em CRLFs, por exemplo, em JPEGs.

Em resumo, você provavelmente não precisa se preocupar muito com essa conversão. No entanto, se você arquivar seu projeto como um tarball, provavelmente os colegas codificadores apreciariam ter terminadores de linha LF em vez de CRLF. Dependendo de quanto você se importa (e dependendo de você não usar o Bloco de Notas), convém configurar o git para usar retornos LF, se puder :)

Apêndice: CR é código ASCII 13, LF é código ASCII 10. Portanto, CRLF é de dois bytes, enquanto LF é um.

Certifique-se de ter instalado o último git.
Eu fiz como acima git config core.autocrlf false, quando usei o git (versão 2.7.1), mas não funcionou.
Então, ele funciona agora ao atualizar o git (de 2.7.1 para 2.20.1).

1. Abra o arquivo no Notepad ++.
2. Vá para Editar / Conversão EOL.
3. Clique no formato Windows.
4. Salve o arquivo.

A pergunta do OP está relacionada ao Windows e eu não poderia usar outras pessoas sem acessar o diretório ou executar o arquivo no Notepad ++, pois o administrador não funcionou.

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

Muitos editores de texto permitem alterar para LF, consulte as instruções Atom abaixo. Simples e explícito.

Clique CRLFno canto inferior direito:

Selecione LFno menu suspenso na parte superior:

Em um prompt de shell do GNU / Linux, os comandos dos2unix e unix2dos permitem converter / formatar facilmente seus arquivos provenientes do MS Windows

O CRLF pode causar algum problema ao usar o seu "código" em dois sistemas operacionais diferentes (Linux e Windows). Meu script python foi escrito no contêiner do docker do Linux e enviado por push usando o Windows git-bash. Me avisou que o LF será substituído pelo CRLF. Não pensei muito nisso, mas quando iniciei o script mais tarde, ele disse /usr/bin/env: 'python\r': No such file or directory. Agora isso é uma \rramificação para você. O Windows usa "CR" - retorno de carro - em cima de '\ n' como novo caractere de linha - \n\r. Isso é algo que você deve considerar.

A maioria das ferramentas do Windows aceita apenas LF em arquivos de texto. Por exemplo, você pode controlar o comportamento do Visual Studio em um arquivo chamado '.editorconfig' com o seguinte exemplo de conteúdo (parte):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Somente o Windows-Notepad original não funciona com o LF, mas existem algumas ferramentas de edição simples mais adequadas disponíveis!

Portanto, você deve usar o LF em arquivos de texto no Windows também. Esta é a minha mensagem, recomendada estritamente! Não há razão para usar o CRLF no Windows!

(A mesma discussão está usando \ in include caminhos no C / ++, é besteira, use #include <pathTo / myheader.h> com barra !, é o padrão C / ++ e todos os compiladores da Microsoft o suportam).

Portanto, a configuração adequada para o git é

git config core.autocrlf false

Minha mensagem: Esqueça programas antigos de pensamento como dos2unix e unix2dos. Esclareça em sua equipe que o LF é adequado para uso no Windows.