Por que devo usar core.autocrlf = true no Git?

Eu tenho um repositório Git que é acessado no Windows e no OS X e que eu sei que já contém alguns arquivos com finais de linha CRLF. Até onde eu sei, existem duas maneiras de lidar com isso:

1. Defina core.autocrlfpara falsequalquer lugar,

2. Siga as instruções aqui (ecoadas nas páginas de ajuda do GitHub) para converter o repositório para conter apenas terminações de linhas LF e, posteriormente, definido core.autocrlfcomo trueno Windows e inputno OS X. O problema é que se eu tiver arquivos binários no repositório aquele:

   1. não estão corretamente marcados como binários em gitattributes e
   2. por acaso contenham CRLFs e LFs,

   eles serão corrompidos. É possível que meu repositório contenha esses arquivos.

Então, por que eu não deveria simplesmente desativar a conversão de final de linha do Git? Há uma série de advertências vagas na web sobre ter core.autocrlfdesligado causando problemas, mas muito poucos específicos queridos; o único que descobri até agora é que o kdiff3 não pode lidar com terminações CRLF (não é um problema para mim) e que alguns editores de texto têm problemas de final de linha (também não são um problema para mim).

O repositório é interno à minha empresa e, portanto, não preciso me preocupar em compartilhá-lo com pessoas com diferentes configurações de autocrlf ou requisitos de final de linha.

Existem outros problemas em deixar os finais de linha como eu desconheço?

As razões única específicos para definir autocrlfa truesão:

• evite git statusmostrar todos os seus arquivos modifieddevido à conversão automática de EOL ao clonar um repositório EOL Git baseado em Unix para um repositório do Windows (consulte o problema 83, por exemplo)
• e suas ferramentas de codificação dependem de algum modo de um estilo EOL nativo presente no seu arquivo:
  • por exemplo, um gerador de código codificado para detectar EOL nativo
  • outros lotes externos (externos ao seu repositório) com regexp ou código definido para detectar EOL nativo
  • Acredito que alguns plugins do Eclipse podem produzir arquivos com CRLF, independentemente da plataforma, o que pode ser um problema.
  • Você codifica com o Notepad.exe (a menos que esteja usando um Windows 10 2018.09+, em que o Bloco de notas respeita o caractere EOL detectado ).

A menos que você possa ver um tratamento específico que deve lidar com a EOL nativa, é melhor sair autocrlfparafalse ( git config --global core.autocrlf false).

Observe que essa configuração seria local (porque a configuração não é enviada de um repositório para outro)

Se você quer a mesma configuração para todos os usuários de clonagem que repo, confira " Qual é a melhor CRLFestratégia de tratamento com git? ", Usando o textatributo no .gitattributesarquivo .

Exemplo:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Nota: a partir do git 2.8 (março de 2016), os marcadores de mesclagem não introduzirão mais o final de linha mista (LF) em um arquivo CRLF.
Consulte " Faça o Git usar CRLF em suas linhas de mesclagem" <<<<<<< HEAD "

Sou desenvolvedor .NET e uso o Git e o Visual Studio há anos. Minha forte recomendação é definir finais de linha como true. E faça isso o mais cedo possível durante a vida útil do seu Repositório.

Dito isto, eu odeio que o Git mude meus finais de linha. Um controle de origem deve salvar e recuperar apenas o trabalho que eu faço, NÃO deve modificá-lo. Sempre. Mas sim.

O que acontecerá se você não tiver todos os desenvolvedores definidos como verdadeiros, é UM desenvolvedor eventualmente definido como verdadeiro. Isso começará a alterar as terminações de linha de todos os seus arquivos para LF no seu repositório. E quando os usuários configurados como falsos, verificá-los, o Visual Studio avisa e solicita que você os altere. Você terá duas coisas que acontecem muito rapidamente. Primeiro, você receberá mais e mais desses avisos, quanto maior sua equipe, mais você recebe. A segunda coisa, e pior, é que ela mostrará que todas as linhas de todos os arquivos modificados foram alteradas (porque as terminações de cada linha serão alteradas pelo cara verdadeiro). Eventualmente, você não poderá mais acompanhar as alterações em seu repo. É MUITO mais fácil e limpo fazer com que todos se mantenham verdadeiros do que tentar manter todos falsos. Por mais horrível que seja viver com o fato de que seu controle de fonte confiável está fazendo algo que não deveria. Sempre.

Atualização 2 :

O Xcode 9 parece ter um "recurso" onde ele ignora as terminações de linha atuais do arquivo e, em vez disso, apenas usa sua configuração de final de linha padrão ao inserir linhas em um arquivo, resultando em arquivos com finais de linha mistos.

Tenho certeza de que esse bug não existia no Xcode 7; não tenho certeza sobre o Xcode 8. A boa notícia é que ele parece estar corrigido no Xcode 10.

Durante o tempo em que ele existiu, esse bug causou uma pequena quantidade de hilaridade na base de código a que me refiro na pergunta (usada até hoje autocrlf=false) e levou a muitas mensagens de confirmação de "EOL" e, eventualmente, à minha escrita de um pre-commitgancho git para verificar para / impedir a introdução de terminações de linhas mistas.

Atualização :

Nota: Como observado por VonC, a partir Git 2.8, marcadores de mesclagem irá não apresentar Unix de estilo linha-finais em um arquivo de estilo do Windows .

Original :

Um pequeno problema que eu notei nessa configuração é que, quando há conflitos de mesclagem, as linhas que o git adiciona para marcar as diferenças não têm finais de linha do Windows, mesmo quando o restante do arquivo possui, e você pode acabar com um arquivo com finais de linha mistos, por exemplo:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Isso não nos causa problemas (imagino que qualquer ferramenta que possa lidar com os dois tipos de final de linha também lida com final de linha misto - certamente todos os que usamos) -, mas é algo para estar ciente.

A outra coisa ^* que descobrimos é que, ao usar git diffpara exibir alterações em um arquivo com finais de linha do Windows, as linhas adicionadas exibem seus retornos de carro, assim:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* Ele realmente não merece o termo: "questão".}