Faire Git "LF sera remplacé par CRLF" les avertissements disparaissent

Question

J'ai configuré Git afin qu'il ne commette pas des fins de ligne incohérentes. Le problème avec cela est qu'une pile entière de fichiers semble être modifiée même si elle ne l'est pas. Que puis-je taper pour faire en sorte que ces extrémités de lignes soient fixées sur le côté local?

# git checkout dev 
M src/au/policy/dao/EmailQueue.java 
M src/au/policy/dao/EmailQueueFactory.java 
M src/au/policy/dao/PolicyPublisher.java 
Already on 'dev' 

# git diff 
warning: LF will be replaced by CRLF in src/au/policy/dao/EmailQueue.java 
warning: LF will be replaced by CRLF in src/au/policy/dao/EmailQueueFactory.java 
warning: LF will be replaced by CRLF in src/au/policy/dao/PolicyPublisher.java 

C'est ce que j'ai ajouté à mon dossier config git qui semble faire ce que je voulais en dehors de cette question:

autocrlf = true 

Answer 1

Vous pouvez simplement supprimer et re-checkout les fichiers incriminés de l'index comme celui-ci:

rm <files> 
git checkout -- <files> 

Ou, si elles sont les seuls fichiers modifiés (attention avec cette commande), vous pouvez écrire des scripts comme ceci:

git diff --name-only --diff-filter=M | xargs rm -- 
git checkout -- . 

sur un système GNU, vous pouvez utiliser un tuyau légèrement plus sûr, mais vous ne semblent pas avoir des espaces ou d'autres caractères dans vos noms de fichiers délimitant dans tous les cas.

git diff -z --name-only --diff-filter=M | xargs -0 rm -- 

Answer 2

La seule chose que je peux penser est de vérifier si core.safecrlf est réglé sur warn.

git config --get core.safecrlf

Je pense que valeurs possibles sont true, false et warn. Je crois que le réglage à false résoudra l'avertissement, bien que ce ne soit pas une bonne idée.

Answer 3

Cela peut se produire si vous changez core.autocrlf variable config (si je comprends bien votre problème).

Si vous êtes à l'état propre, soit juste après engagement, et vous n'avez pas des changements uncomitted, Forcé re-caisse et l'index suppression devrait faire l'affaire:

La commande ci-dessous git reset --hard HEAD sera faites en sorte que votre branche actuelle pointe vers la dernière validation et que tout le code non validé soit perdu. Assurez-vous de commettre le code ou prendre la sauvegarde

$ rm .git/index 
$ git reset --hard HEAD 

Cela, je pense, se synchroniser les fichiers de la zone de travail, et l'indice (zone de stockage intermédiaire) pour suivre les paramètres CRLF.

Answer 4

Essayez cela, il a travaillé pour moi:

cd src/au/policy/dao 
dos2unix 

S'il y a d'autres fichiers dans ce dossier, alors vous aurez envie de le casser dans le suivant (sinon il va essayer de le faire sur tous les fichier dans les sous-répertoires, ce qui peut prendre un certain temps):

cd src/au/policy/dao 
dos2unix EmailQueue.java 
dos2unix EmailQueueFactory.java 
dos2unix PolicyPublisher.java 

il a couru vraiment rapide sur ma machine et fixe toutes les fins de ligne, et il est un peu plus simple et plus facile que certains de ces autres correctifs.

Answer 5

J'ai rencontré ce problème lors de la création d'un nouveau projet Xcode. Ma solution pour ce problème:

En écriture terminale

$: git config --global --edit 

Ensuite, dans le changement de fichier de configuration git safecrlf-faux. Mes paramètres:

[core] 
    autocrlf = input 
    safecrlf = false 

Je sais que git a des outils de ligne cmd pour cela mais ils ne fonctionnent pas pour moi. Puis Xcode crée des dépôts git sans aucun problème.