Tentei confirmar arquivos com linhas que terminam com CRLF, mas falharam.

Passei um dia inteiro de trabalho no meu computador Windows tentando estratégias diferentes e quase me senti atraído por parar de tentar usar o Git e, em vez disso, experimentar o Mercurial .

Compartilhe apenas uma prática recomendada por resposta.

Quase quatro anos depois de fazer essa pergunta, finalmente encontrei uma resposta que me satisfaz completamente !

Veja os detalhes no github: guia de ajuda para Lidando com terminações de linha .

O Git permite que você defina as propriedades de final de linha de um repositório diretamente usando o atributo de texto no .gitattributesarquivo. Esse arquivo é confirmado no repositório e substitui a core.autocrlfconfiguração, permitindo garantir um comportamento consistente para todos os usuários, independentemente de suas configurações de git.

E assim

A vantagem disso é que sua configuração de final de linha agora viaja com seu repositório e você não precisa se preocupar se os colaboradores têm ou não as configurações globais apropriadas.

Aqui está um exemplo de .gitattributesarquivo

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Há uma coleção conveniente de arquivos .gitattributes prontos para usar para as linguagens de programação mais populares. É útil para você começar.

Depois de criar ou ajustar o seu .gitattributes, você deve executar uma re-normalização de terminações de uma vez por todas .

Observe que o aplicativo GitHub Desktop pode sugerir e criar um .gitattributesarquivo depois de abrir o repositório Git do seu projeto no aplicativo. Para tentar isso, clique no ícone de roda dentada (no canto superior direito)> Configurações do repositório ...> Finais e atributos de linha. Você será solicitado a adicionar o recomendado .gitattributese, se concordar, o aplicativo também executará uma normalização de todos os arquivos em seu repositório.

Por fim, o artigo Mind the End of Your Line fornece mais informações e explica como o Git evoluiu nos assuntos em questão. Considero essa leitura obrigatória .

Você provavelmente tem usuários em sua equipe que usam EGit ou JGit (ferramentas como Eclipse e TeamCity os usam) para confirmar suas alterações. Então você está sem sorte, como @gatinueta explicou nos comentários desta resposta:

Essa configuração não irá satisfazê-lo completamente se você tiver pessoas trabalhando com Egit ou JGit em sua equipe, pois essas ferramentas apenas ignoram os atributos .gitat e conferem com alegria os arquivos CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

Um truque pode ser fazê-los confirmar suas alterações em outro cliente, diz o SourceTree . Nossa equipe naquela época preferia essa ferramenta ao EGit do Eclipse para muitos casos de uso.

Quem disse que o software é fácil? : - /

Não converta terminações de linha. Não é tarefa do VCS interpretar dados - apenas armazene e faça a versão. Todo editor de texto moderno pode ler os dois tipos de finais de linha de qualquer maneira.

Você quase sempre quer, a autocrlf=inputmenos que saiba realmente o que está fazendo.

Alguns contextos adicionais abaixo:

Deve ser core.autocrlf=truese você gosta de terminar o DOS ou core.autocrlf=inputse prefere as novas linhas unix. Nos dois casos, seu repositório Git terá apenas LF, que é a coisa certa. O único argumento core.autocrlf=falsefoi que a heurística automática pode detectar incorretamente alguns binários como texto e, em seguida, seu bloco será corrompido. Portanto, a core.safecrlfopção foi introduzida para avisar um usuário se uma alteração irreversível acontecer. De fato, existem duas possibilidades de mudanças irreversíveis - final de linha misto no arquivo de texto, nesta normalização é desejável, portanto esse aviso pode ser ignorado ou (muito improvável) que o Git detectou incorretamente o seu arquivo binário como texto. Então você precisa usar atributos para informar ao Git que este arquivo é binário.

O parágrafo acima foi originalmente retirado de um tópico no gmane.org, mas caiu desde então.

Duas estratégias alternativas para obter consistência sobre terminações de linha em ambientes mistos (Microsoft + Linux + Mac):

A. Configuração global por todos os repositórios

1) Converta tudo em um formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Defina core.autocrlfcomo inputno Linux / UNIX ou trueno MS Windows (repositório ou global)

git config --global core.autocrlf input

3) [Opcional] defina core.safecrlfcomo true(para parar) ou warn(para cantar :) para adicionar proteção extra comparando se a transformação de nova linha reversa resultaria no mesmo arquivo

git config --global core.safecrlf true

B. Ou por configuração do repositório

1) Converta tudo em um formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) adicione o .gitattributesarquivo ao seu repositório

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Não se preocupe com seus arquivos binários - o Git deve ser inteligente o suficiente sobre eles.

Mais sobre variáveis ​​safecrlf / autocrlf

Tente definir a core.autocrlfopção de configuração para true. Também dê uma olhada na core.safecrlfopção.

Na verdade, parece que core.safecrlfjá pode estar definido no seu repositório, porque (ênfase minha):

Se esse não for o caso da configuração atual do core.autocrlf, o git rejeitará o arquivo .

Se for esse o caso, convém verificar se o seu editor de texto está configurado para usar as terminações de linha de forma consistente. Você provavelmente terá problemas se um arquivo de texto contiver uma mistura de terminações de linha LF e CRLF.

Por fim, sinto que a recomendação de simplesmente "usar o que você recebeu" e usar linhas terminadas por LF no Windows causará mais problemas do que resolve. O Git tem as opções acima para tentar manipular as terminações de linha de maneira sensata, por isso faz sentido usá-las.

O uso core.autocrlf=falseinterrompeu a atualização de todos os arquivos assim que os fiz no meu projeto do Visual Studio 2010 . Os outros dois membros da equipe de desenvolvimento também estão usando sistemas Windows para que um ambiente misto não entre em jogo, mas as configurações padrão que acompanham o repositório sempre marcam todos os arquivos como atualizados imediatamente após a clonagem.

Eu acho que a linha inferior é descobrir qual configuração CRLF funciona para o seu ambiente. Especialmente porque em muitos outros repositórios em nossas caixas de Linux, a configuração autocrlf = trueproduz melhores resultados.

Mais de 20 anos depois e ainda estamos lidando com disparidades de final de linha entre sistemas operacionais ... triste.

Essas são as duas opções para usuários do Windows e do Visual Studio que compartilham código com usuários do Mac ou Linux . Para uma explicação detalhada, leia o manual gitattributes .

* texto = automático

No .gitattributesarquivo do seu repo, adicione:

*   text=auto

Isso normalizará todos os arquivos com LFfinais de linha no repositório.

E, dependendo do seu sistema operacional ( core.eolconfiguração), os arquivos na árvore de trabalho serão normalizados LFpara sistemas baseados em Unix ou CRLFsistemas Windows.

Essa é a configuração que os repositórios Microsoft .NET usam.

Exemplo:

Hello\r\nWorld

Será normalizado no repositório sempre como:

Hello\nWorld

Na finalização da compra, a árvore de trabalho no Windows será convertida em:

Hello\r\nWorld

No checkout, a árvore de trabalho no Mac será deixada como:

Hello\nWorld

Nota: Se o seu repositório já contiver arquivos não normalizados, eles git statusserão mostrados como completamente modificados na próxima vez que você fizer alguma alteração neles, e pode ser um problema para outros usuários mesclar suas alterações posteriormente. Consulte a atualização de um repositório após alterar as terminações de linha para obter mais informações.

core.autocrlf = true

Se textnão for especificado no .gitattributesarquivo, o Git usará a core.autocrlfvariável de configuração para determinar se o arquivo deve ser convertido.

Para usuários do Windows, git config --global core.autocrlf trueé uma ótima opção porque:

• Os arquivos são normalizados para LFfinais de linha somente quando adicionados ao repositório. Se houver arquivos não normalizados no repositório, essa configuração não os tocará.
• Todos os arquivos de texto são convertidos em CRLFfinais de linha no diretório ativo.

O problema com essa abordagem é que:

• Se você é usuário do Windows autocrlf = input, verá vários arquivos com LFfinais de linha. Não é um risco para o resto da equipe, porque seus commit ainda serão normalizados com LFfinais de linha.
• Se você é usuário do Windows core.autocrlf = false, verá vários arquivos com LFfinais de linha e poderá introduzir arquivos com CRLFfinal de linha no repositório.
• A maioria dos usuários de Mac usa autocrlf = inpute pode obter arquivos com CRLFfinais de arquivos, provavelmente de usuários do Windows com core.autocrlf = false.

--- ATUALIZAÇÃO 3 --- (não entra em conflito com a ATUALIZAÇÃO 2)

Considerando o caso em que os usuários do Windows preferem trabalhar CRLFe os usuários Linux / Mac preferem trabalhar em LFarquivos de texto. Fornecendo a resposta da perspectiva de um mantenedor de repositório :

Para mim, a melhor estratégia (menos problemas a resolver) é: mantenha todos os arquivos de texto com o LFgit repo, mesmo se você estiver trabalhando em um projeto somente para Windows. Em seguida, permita que os clientes trabalhem no estilo de final de linha de sua preferência , desde que eles escolham um core.autocrlfvalor de propriedade que respeite sua estratégia (LF no repo) enquanto prepara arquivos para confirmação.

A preparação é o que muitas pessoas confundem ao tentar entender como as estratégias de nova linha funcionam. É essencial entender os seguintes pontos antes de escolher o valor correto para a core.autocrlfpropriedade:

• Adicionar um arquivo de texto para confirmação ( prepará- lo) é como copiar o arquivo para outro local dentro .git/do subdiretório com finais de linha convertidos (dependendo do core.autocrlfvalor da configuração do cliente). Tudo isso é feito localmente.
• configuração core.autocrlfé como fornecer uma resposta para a pergunta (exatamente a mesma pergunta em todos os sistemas operacionais):
  • "O git-client a. Converte LF em CRLF ao fazer check-out (puxando) o repo muda do controle remoto ou b. Converte CRLF em LF ao adicionar um arquivo para confirmação? " E as possíveis respostas (valores) estamos:
  • false:" não execute nenhuma das opções acima ",
  • input:" faça apenas b "
  • true: " faça aeb "
  • note que NÃO existe " faça apenas um "

Felizmente

• Os padrões do cliente git (windows core.autocrlf: true:, linux / mac:) core.autocrlf: falseserão compatíveis com a estratégia LF-only-repo .
  Significado : os clientes do Windows, por padrão, serão convertidos em CRLF ao fazer check-out do repositório e convertidos em LF ao adicionar para confirmação. E os clientes linux, por padrão, não fazem conversões. Teoricamente, isso mantém o seu repositório apenas.

Infelizmente:

• Pode haver clientes GUI que não respeitam o core.autocrlfvalor git
• Pode haver pessoas que não usam um valor para respeitar sua estratégia de lf-repo. Por exemplo, eles usam core.autocrlf=falsee adicionam um arquivo com CRLF para confirmação.

Para detectar arquivos de texto ASAP não lf confirmados pelos clientes acima, você pode seguir o que está descrito em --- atualização 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, em um cliente compilado usando: --with-libpcreflag)

E aqui está o problema: . Como mantenedor de repositório, mantenho um git.autocrlf=inputarquivo para que eu possa corrigir todos os arquivos confirmados incorretamente apenas adicionando-os novamente para confirmação. E forneço um texto de confirmação: "Corrigindo arquivos confirmados incorretamente".

Tanto quanto .gitattributesé aprendido. Não conto com isso, porque há mais clientes de interface do usuário que não entendem. Só o uso para fornecer dicas para arquivos binários e de texto e talvez sinalizar alguns arquivos excepcionais que devem manter em todos os lugares as mesmas terminações de linha:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Pergunta: Mas por que estamos interessados ​​na estratégia de manipulação de novas linhas?

Resposta: Para evitar uma confirmação de alteração de letra única, apareça como uma alteração de 5000 linhas , apenas porque o cliente que executou a alteração converteu automaticamente o arquivo completo de crlf para lf (ou o oposto) antes de adicioná-lo para confirmação. Isso pode ser bastante doloroso quando há uma resolução de conflito envolvida. Ou, em alguns casos, pode ser a causa de conflitos irracionais.

--- ATUALIZAÇÃO 2 ---

Os padrões do cliente git funcionarão na maioria dos casos. Mesmo se você tiver apenas clientes com Windows, Linux apenas com clientes ou ambos. Esses são:

• windows: core.autocrlf=true significa converter linhas em CRLF no checkout e converter linhas em LF ao adicionar arquivos.
• linux: core.autocrlf=input significa não converter linhas no checkout (não é necessário, pois é esperado que os arquivos sejam comprometidos com o LF) e converter linhas em LF (se necessário) ao adicionar arquivos. ( - update3 - : parece que está falsepor padrão, mas novamente está bom)

A propriedade pode ser configurada em diferentes escopos. Eu sugeriria definir explicitamente o --globalescopo, para evitar alguns problemas de IDE descritos no final.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Também desencorajaria fortemente o uso no Windows git config --global core.autocrlf false (no caso de você possuir apenas clientes Windows), em contraste com o que é proposto para a documentação do git . Definir como false confirmará os arquivos com CRLF no repositório. Mas realmente não há razão. Você nunca sabe se precisará compartilhar o projeto com os usuários do Linux. Além disso, é uma etapa extra para cada cliente que ingressa no projeto em vez de usar os padrões.

Agora, para alguns casos especiais de arquivos (por exemplo *.bat *.sh), nos quais você deseja que eles sejam verificados com LF ou com CRLF, você pode usar.gitattributes

Para resumir, a melhor prática é:

• Verifique se todos os arquivos não binários estão confirmados com o LF no git repo (comportamento padrão).
• Use este comando para certificar-se de que nenhum arquivo seja confirmado com o CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Nota: no windows clients funciona apenas através git-bashe no linux clients somente se compilado usando --with-libpcrein ./configure).
• Se você encontrar esses arquivos executando o comando acima, corrija-os. Isso envolve (pelo menos no linux):
  • set core.autocrlf=input( --- atualização 3 - )
  • mudar o arquivo
  • reverter a alteração (o arquivo ainda é mostrado como alterado)
  • comprometa
• Use apenas o mínimo necessário .gitattributes
• Instrua os usuários a definir o core.autocrlfdescrito acima para seus valores padrão.
• Não conte 100% na presença de .gitattributes. os clientes-git dos IDEs podem ignorá-los ou tratá-los de maneira diferente.

Como dito, algumas coisas podem ser adicionadas nos atributos git:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Eu acho que algumas outras opções seguras para, em .gitattributesvez de usar a detecção automática de arquivos binários:

• -text(por exemplo, para *.zipou *.jpgarquivos: não serão tratados como texto. Portanto, nenhuma conversão de final de linha será tentada. A diferença pode ser possível através de programas de conversão)
• text !eol(por exemplo *.java, for *.html:: tratado como texto, mas a preferência de estilo eol não está definida. Portanto, a configuração do cliente é usada.)
• -text -diff -merge(por exemplo, para *.hugefile: Não tratado como texto. Não é possível obter diferenças / mesclagens)

--- ATUALIZAÇÃO ANTERIOR ---

Um exemplo doloroso de um cliente que confirmará arquivos incorretamente:

O netbeans 8.2 (no Windows) comprometerá erroneamente todos os arquivos de texto com CRLFs, a menos que você tenha definido explicitamente core.autocrlfcomo global . Isso contradiz o comportamento padrão do cliente git e causa muitos problemas posteriormente, durante a atualização / mesclagem. É isso que faz com que alguns arquivos pareçam diferentes (embora não sejam), mesmo quando você reverte .
O mesmo comportamento no netbeans acontece mesmo se você adicionou o correto .gitattributesao seu projeto.

Usar o comando a seguir após uma confirmação, pelo menos, ajudará a detectar com antecedência se o seu repositório git tem problemas de final de linha: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Passei horas para encontrar o melhor uso possível .gitattributes, para finalmente perceber, que não posso contar com isso.
Infelizmente, enquanto existirem editores baseados em JGit (que não podem ser manipulados .gitattributescorretamente), a solução segura é forçar o LF em qualquer lugar, mesmo no nível do editor.

Use os seguintes anti-CRLFdesinfetantes.

• clientes windows / linux: core.autocrlf=input

• comprometido .gitattributes: * text=auto eol=lf

• commit .editorconfig( http://editorconfig.org/ ), que é um tipo de formato padronizado, combinado com plugins de editor:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Esta é apenas uma solução alternativa :

Em casos normais, use as soluções fornecidas com o git. Estes funcionam muito bem na maioria dos casos. Força para LF se você compartilhar o desenvolvimento em sistemas baseados em Windows e Unix, definindo .gitattributes .

No meu caso, havia> 10 programadores desenvolvendo um projeto no Windows. Este projeto foi verificado com o CRLF e não havia opção para forçar o LF.

Algumas configurações foram gravadas internamente na minha máquina sem nenhuma influência no formato LF; portanto, alguns arquivos foram globalmente alterados para LF em cada alteração de arquivo pequeno.

Minha solução:

Máquinas Windows: Deixe tudo como está. Não se preocupe com nada, já que você é um desenvolvedor padrão de 'lobo solitário' e precisa lidar com o seguinte: "Não existe outro sistema no mundo inteiro, é?"

Máquinas Unix

1. Adicione as seguintes linhas à [alias]seção de uma configuração . Este comando lista todos os arquivos alterados (isto é, modificados / novos):

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Converta todos os arquivos alterados no formato dos:

   unix2dos $(git lc)

3. Opcionalmente ...

   1. Crie um gancho git para esta ação para automatizar esse processo

   2. Use parâmetros e inclua-o e modifique a grepfunção para corresponder apenas a nomes de arquivos específicos, por exemplo:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Sinta-se à vontade para torná-lo ainda mais conveniente usando um atalho adicional:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... e dispare o material convertido digitando

      git c2dos