git substituindo LF por CRLF


840

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.


14
@apphacker porque a padronização das terminações de linha é menos irritante do que ter que alterá-las quando você difere dois arquivos. (E, claro, se você discordar, poderá manter o recurso core.autocrlf desativado).
RJFalconer

2
por que os fins de linha ser diferente, a menos que toda a linha foi tocado
Bjorn

3
Costumo tocar muitas linhas, porque estou experimentando idéias diferentes, adicionando instruções de rastreio para ver como elas funcionam etc. Então, talvez eu queira apenas fazer uma alteração em duas ou três linhas e ter ignorado completamente as outras porque eu tinha colocado de volta do jeito que eu os encontrei (ou assim eu pensei).
MatrixFrog

5
@MatrixFrog: seu editor parece quebrado, incapaz de detectar automaticamente as terminações de linha. Qual é? Trabalho em projetos híbridos que devem ter alguns arquivos LF e outros arquivos CRLF no mesmo repositório. Não é um problema para qualquer editor moderno. Ter uma bagunça no controle de versão (ou transferência de arquivos) com terminações de linha para solucionar as limitações do editor é a pior idéia de todos os tempos - óbvia pelo mero comprimento das explicações abaixo.
MarcH 29/07

4
O único editor moderno que conheço que faz a coisa errada é o Visual Studio. O Visual Studio abrirá um arquivo com final de linha LF. Se você inserir novas linhas, ele inserirá CRLF e salvará as terminações de linhas mistas. A Microsoft se recusa a consertar isso, o que é um grande defeito em um IDE muito bom: - (
Jon Watte 7/15/15

Respostas:


957

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.


28
Para a quantidade de tempo que passei para chegar até aqui, eu estava esperando por uma core.crlf = Rackoff ;-)
PandaWood

10
I reestruturou o conteúdo, talvez seja mais fácil de ler desta forma
Antony Hatchkins

7
desculpe, espero que meu comentário não tenha sido considerado uma crítica à sua resposta. Por "chegar até aqui", quero dizer, antes de encontrar esta resposta.
PandaWood 21/01

10
Isso é tão confuso. Eu tenho LF definido no meu editor. Todo o código repo usa LF. autocrlf global está definido como false e o núcleo gitconfig no diretório home está definido como false. Mas ainda recebo a mensagem LF sendo substituída por CRLF
isimmons

17
Se você configurou seu editor para usar finais de estilo Unix, por que não definir core.autocrlfa entrada? Pelo que eu coletei de sua resposta, configurá-lo como entrada garante que o repositório e o diretório de trabalho sempre tenham finais de linha no estilo unix. Por que você nunca iria querer isso no Windows?
Hubro 14/11

764

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".


116
Como dito aqui ( stackoverflow.com/questions/1249932/… ), eu respeitosamente discordo e deixo essa configuração em OFF (e uso o Notepad ++ ou qualquer outro editor capaz de lidar com - e deixar como está - qualquer caractere de linha final encontra)
VonC 28/09/09

23
Gosto dessa resposta e prefiro deixar o autocrlf definido como verdadeiro. Como alternativa, existe uma maneira de eliminar as mensagens de aviso automaticamente?
Krisc 28/01

12
Seria bom aumentar esta resposta bem escrita com uma comparação com as core.eolconfigurações, talvez em conjunto com a .gitattributesconfiguração. Eu tenho tentado descobrir as diferenças e sobreposições através da experimentação, e é muito confuso.
seh

5
Para uma mudança solução mais permanente o seu .gitconfig para: [core] autocrlf = false
RBZ

9
Existe alguma maneira fácil de apagar o aviso? Eu quero que seja verdade e saiba que eu a configurei como verdadeira. Eu não preciso ver todos os avisos o tempo todo ... Está tudo bem, realmente ...: p
UmaN

160

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.


23
Obrigado por uma maneira simples, clara e multiplataforma de corrigi-lo, em vez de uma grande discussão sobre o significado da configuração.
218 Eris

2
se git reset --hard é possível que minha alteração local seja perdida? eu apenas sigo todos os comentários acima
Freddy Sidauruk

5
Sim, suas alterações locais serão perdidas. O parâmetro --hard redefine o índice e a árvore de trabalho para que quaisquer alterações nos arquivos rastreados sejam descartadas. git-scm.com/docs/git-reset
Jacques

2
Qual é o significado git rm --cached -r .? Por que git reset --hardnão é suficiente?
precisa saber é o seguinte

2
@gavenkoa @max Você precisa do git rm --cached -r .Se você o fizer git reset --harddepois de alterar a core.autocrlfconfiguração, ele não converterá novamente as terminações de linha. Você precisa limpar o índice git.
wisbucky

80
git config core.autocrlf false

6
certifique-se de executar essa raiz do repositório dentro
Hammad Khan

23
Não entendo como isso pode ser útil. Metade das pessoas exige que o autocrlf seja verdadeiro para que ele funcione, a outra metade precisa que seja falso / input. Então, o que eles deveriam jogar aleatoriamente essas respostas pontuais na parede do console até que algo grude e meio que "funcione"? Isso não é produtivo.
Zoran Pavlovic

Eu recebo um erro "fatal: não em um diretório git". Tentei cd para C: \ Program Files \ Git e C: bin \ Program Files \ Git \
pixelwiz

2
@mbb configuração autcrlfpara falseapenas punts a questão para todos os usuários do seu projeto.
jpaugh

5
@pixelwiz: este comando está configurando a propriedade apenas para o projeto (portanto, você precisa estar em um repositório git para executá-lo). Se você deseja definir isso globalmente, use git config --global core.autocrlf false.
Michaël Polla

49

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.


8
O que isso faz?
Salman von Abbas

1
Aqui está o que a opção de ajuda diz: `--u2d, -D executa UNIX -> conversão do DOS` #
Larry Battle

1
@ Rifat Estou confuso. Seu comentário diz que dos2unix -Disso converterá as terminações de linha do Windows em finais de linha Linux. Não é o mesmo que a conversão do DOS (CRLF) -> UNIX (LF). No entanto, dos2unix -hafirma que -Dexecutará a conversão UNIX (LF) -> DOS (CRLF). dos2unix Mais informações: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix
Larry Battle

1
@ LarryBattle Sim, você está certo sobre -D. Na verdade, eu postei a resposta quando eu era um usuário do Windows. E, eu fiz o comentário mais de um ano depois, quando eu sou um usuário de mac: D BTW, Obrigado pelo esclarecimento.
Rifat

1
Isso funcionou para mim. Estou usando o Cygwin, que parece não suportar a opção -D - mas existe o comando "unix2dos", que faz a mesma coisa. Eu gostaria de saber o que causou o problema - eu tenho core.autocrlf = false e é um repositório somente para Windows.
Richard Beier

28

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).


1
Deve ser safecrlf(com um 'f')
alpipego

22

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.


Correndo para isso agora, tentando gerenciar um repositório com scripts Cygwin, entre outros arquivos de texto básicos. Como você lida com arquivos sem extensão (por exemplo, "fstab", "sshd_config")? O artigo vinculado não cobre esse cenário.
Mike Loux

1
@MikeLoux Tente este método: stackoverflow.com/a/44806034/4377192
Gene Pavlovsky

Descobri que text=false eol=falsefuncionava de maneira semelhante à binary. Isso soa certo? Pode ser útil para indicar "Eu sei que estes são arquivos de texto, mas eu não quero que eles ser normalizada"
joeytwiddle

19

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

:set noendofline binary
:wq

2
Simplesmente editar com vimdeixaria toda a linha final intacta.
do olho

Eu estou tendo esse problema com alguns arquivos Cocoapods. O acima consertou a maioria deles; quanto ao resto, s / {control-v} {control-m} // fez o truque. Os dois códigos de controle juntos formam o ^ M que nós, no OS X, costumamos ver nos arquivos do Windows.
23413 janineanne

16

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.


2
Eu acho que há uma quarta opção a ser adicionada à sua lista, supondo que se possa reescrever o histórico: você pode fazer um repositório git que você criou inicialmente com o git-svn e reescrever seu histórico para não ter mais feeds de linha CRLF. Isso daria a você feeds de linha normalizados que se estendem para trás ao longo de todo o seu histórico de svn. O usuário keo apresenta uma solução em stackoverflow.com/a/1060828/64257 .
28412 Chris

Sobre sua nota de rodapé: rebasenão há problemas com o CRLF. O único problema que conheço é que a ferramenta de mesclagem git padrão inserirá seus marcadores de conflito ("<<<<<<", ">>>>>>" etc.) apenas com LF, portanto, um arquivo com marcadores de conflito têm finais de linha mistos. No entanto, depois de remover os marcadores, tudo está bem.
sleske

É possível que o manuseio do git tenha mudado nos últimos 3 anos, essa foi minha experiência direta com ele na época, não precisei revisar esse problema em particular desde então. ymmv.
precisa

1
@sleske, iniciando o git 2.8, os marcadores de mesclagem não introduzirão mais final de linha mista. Veja stackoverflow.com/a/35474954/6309
VonC

@VonC: Isso é legal. É bom saber os horários em que preciso trabalhar no Windows.
sleske

12

Removendo o abaixo do arquivo ~ / .gitattributes

* text=auto

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


6
Incorreta. Essa linha, se presente, substituirá a configuração do core.autocrlf. Se isso estiver definido como 'true', não, remover essa linha não impedirá que o git verifique as terminações da linha.
Arafangion

1
No entanto, se core.autocrlf estiver definido como false, se este não for removido, configurar o autocrlf como false não ajudará muito, então este me ajudou (mas, por si só, não é suficiente).
Matty

2
Voto positivo !! Embora a parte "impeça a verificação do git" não seja tecnicamente correta, esta é a ÚNICA resposta que menciona especificamente a text=configuração .gitattributes(que, se presente, será um bloqueador). Portanto, as outras respostas estão incompletas. Eu estava indo nozes figura tentar descobrir por que meus arquivos continuou a mostrar-se como "modificado" não importa quantas vezes eu mudei autocrlfe safecrlfconfigurações e check-out e limpar o cache git & hard reset.
jdunk

10

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. insira a descrição da imagem aqui


Isso também significa que o que é enviado para o Subversion (se você fizer isso) terá a conversão.
jpaugh

10

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.


2
Isso é especialmente útil quando você deseja converter entre CRLF e LF, mas você tem alguns arquivos .sh que devem permanecer intactos. Eu uso *.sh -crlfo tempo todo ...
MartinTeeVarga

9

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.


5
Como ninguém parece ter dito isso, CR significa "Retorno de carro" e LF significa "Alimentação de linha". Como uma segunda observação, muitos editores do Windows alteram silenciosamente um arquivo de texto com o caractere LF que denota uma nova linha para, em vez disso, ser o par de caracteres CRLF. O usuário do editor nem será avisado, mas o Git verá a mudança.
User2548343

7

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).


Eu acho que você quis dizer que tinha o git 2.17.1. Eu estava tendo o mesmo problema e fiz a atualização e isso também foi corrigido. Ainda bem que vi sua resposta!
Phillip McMullen

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

1
Tente também usar git config --global core.autocrlf falsepara impedir que o Git defina as terminações de linha Unixem uma confirmação. Faça o acompanhamento git config core.autocrlfpara verificar se está realmente definido como falso.
Contango 27/06

5

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

3

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


Clique CRLFno canto inferior direito:

insira a descrição da imagem aqui

Selecione LFno menu suspenso na parte superior:

insira a descrição da imagem aqui


2

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


2

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.


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.