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

Eu tenho um repository Git que é acessado a partir do Windows e OS X, e que eu já conheço alguns arquivos com finais de linha CRLF. Tanto quanto eu posso dizer, existem duas maneiras de lidar com isso:

  1. Definir core.autocrlf para false todos os lugares,

  2. Siga as instruções aqui (ecoadas nas páginas de ajuda do GitHub) para converter o repository para conter apenas as extremidades da linha LF e, depois disso, configure core.autocrlf para true no Windows e input no OS X. O problema em fazer isso é que se eu tiver algum arquivos binários no repository que:

    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 repository contenha tais arquivos.

Então, por que eu não deveria simplesmente desligar a conversão de fim de linha do Git? Há um monte de avisos vagos na web sobre ter core.autocrlf desligado causando problemas, mas muito poucos específicos ; o único que eu encontrei até agora é que o kdiff3 não pode lidar com finais CRLF (não é um problema para mim), e que alguns editores de texto têm problemas de finalização de linha (também não é um problema para mim).

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

Há algum outro problema em apenas deixar fins de linha, como eu desconheço?

As únicas razões específicas para definir autocrlf como true são:

  • evite o git status mostrando todos os seus arquivos modified por causa da conversão automática de EOL feita ao clonar um repository EOL Git baseado em Unix para um Windows one (consulte a edição 83, por exemplo)
  • e suas ferramentas de codificação de alguma forma dependem de um estilo EOL nativo estar presente em seu arquivo:
    • por exemplo, um gerador de código codificado para detectar EOL nativo
    • outros lotes externos (externos ao seu repository) com regexp ou conjunto de códigos para detectar EOL nativo
    • Eu acredito que alguns plugins do Eclipse podem produzir arquivos com CRLF independentemente da plataforma, o que pode ser um problema.

A menos que você possa ver um tratamento específico que deve lidar com a EOL nativa, é melhor deixar a autocrlf como false .

Note que esta configuração seria local (porque a configuração não é empurrada do repo para o repo)

Se você quiser a mesma configuração para todos os usuários clonando o repository, verifique ” Qual é a melhor estratégia de manipulação de CRLF com o git? “, Usando o atributo text no arquivo .gitattributes .


Nota: iniciando o git 2.8 (março de 2016), os marcadores de mesclagem não mais introduzirão o alinhamento de linhas mistas (LF) em um arquivo CRLF.
Consulte ” Faça o Git usar o CRLF em suas linhas de mesclagem < <<<<<< HEAD" "

Eu sou um desenvolvedor .NET e usei o Git e o Visual Studio por anos. Minha forte recomendação é definir os 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 Git muda meus finais de linha. Um controle de origem só deve salvar e recuperar o trabalho que eu faço, ele não deve modificá-lo. Sempre. Mas isso acontece.

O que acontecerá se você não tiver todos os desenvolvedores definidos como verdadeiros, se um desenvolvedor for definido como verdadeiro. Isto irá começar a mudar os finais de linha de todos os seus arquivos para LF em seu repo. E quando os usuários configuram para falso, verifique se o Visual Studio irá avisá-lo e peça para alterá-los. Você terá duas coisas acontecendo muito rapidamente. Um, você receberá mais e mais desses avisos, quanto maior o seu time, mais você terá. O segundo, e o pior, é que ele mostrará que cada linha de cada arquivo modificado foi alterada (porque os finais de linha de cada linha serão alterados pelo verdadeiro cara). Eventualmente, você não poderá mais acompanhar as alterações em seu repository de maneira confiável. É MUITO MAIS FÁCIL E MAIS LIMPO para fazer com que todos se mantenham fiéis, 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, não deveria. Sempre.

Atualização :

Nota: Conforme observado pelo VonC, a partir do Git 2.8, os marcadores de mesclagem não introduzirão fins de linha no estilo Unix em um arquivo no estilo do Windows .

Original :

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

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

Isso não nos causa nenhum problema (imagino que qualquer ferramenta que possa lidar com ambos os tipos de terminações de linha também seja sensata com o fim de linha misto – certamente todos os que usamos), mas é algo que deve estar ciente.

A outra coisa * que descobrimos é que, ao usar o git diff para visualizar as alterações em um arquivo que possui finais de linha do Windows, as linhas que foram adicionadas exibem seus retornos de carro, assim:

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

* Realmente não merece o termo: “problema”.