Recomendação definitiva para configurações de git autocrlf

Eu uso o Windows, Mac OS X e Linux diariamente. Eu uso o git em todos esses ambientes, puxando de repositorys que são usados ​​por pessoas com diferentes opções para finais de linha.

Há uma recomendação definitiva para definir core.autocrlf na minha situação?

Eu recomendaria, como fiz nesta pergunta SO , configurá-lo para false.

Se você pode evitar modificar qualquer eol (com o seu editor), então seria melhor empurrar de volta o seu trabalho com o eol inalterado (ou seja, “como você os encontrou”).

Uma questão que muitas vezes não é mencionada nestas discussões: se você desenvolver scripts de shell no windows (digamos, no cygwin) e enviá-los com CRLF (autocrlf = false), eles falharão em checkboxs * nix com mensagens de erro inúteis. (Pode haver casos semelhantes com outras linguagens de script.) Depois de coçar a cabeça por meia hora, você vai se lembrar e depois dos2unix os pequenos patifes. Se você trabalha em um ambiente misto (digamos, implantando a partir do Windows em um servidor linux) e quer absolutamente definir autocrlf como false, certifique-se de que todos os editores do Windows usem finais de linha unix (lf). Caso contrário, defina autocrlf para inserir (e orar). A maioria dos programas do Windows do século XXI são confortáveis ​​sem os CRs da impressora de linha do início dos anos 80, portanto, é uma boa idéia definir seus fins de linha como LF (unix) de qualquer maneira.

O GIT NÃO teria SHA1’s comuns para dois arquivos de texto com texto idêntico , mas diferentes mecanismos de fim de linha (EOL) dentro da representação binária. O conteúdo é armazenado como um blob, que é reutilizado se outra cópia idêntica for eliminada no reposicionamento (economia de espaço!)

A escolha padrão escolhida pelo (o) GIT (designers) é usar o caractere EOL do estilo * nix (somente LF) sempre que possível, para que, para o mesmo conteúdo de texto , você obtenha o mesmo SHA1. (provavelmente uma consideração importante 😉

Como o conteúdo / blob não lembra mais a opção EOL original do usuário (lembre-se que possivelmente agora está em algum repository distante), Git precisa fazer algumas suposições (baseadas em opções) sobre como recriar o arquivo do usuário original (era CRLF ou simplesmente LF) de uma maneira que você (e suas ferramentas) podem usar.

A recomendação normal é que localmente cada usuário (a) converta para terminações * nix LF ao cometer um blob (para que todos vejam os nomes comuns de blob SHA1) (a / k / a the Right Thing), e (b) defina localmente opção de recriação para sua configuração de sistema local, por exemplo, * nix (LF) ou Windows (CRLF), etc.

Defina alguns padrões locais para seus usuários, e tenha um grande commit ‘EOL / LF / CRLF e Whitespace Correction’, e você estará bem (além de treinar o re-treinamento de novos usuários)

Você também pode garantir que você (cada usuário) use uma configuração de espaço em branco comum para que as guias v espaços e espaços em branco à direita não causem mais inconvenientes de diff !