Comment normaliser les terminaisons des lignes d'arbres de travail dans Git ?

Question

J'ai cloné un référentiel qui avait des fins de lignes incohérentes. J'ai ajouté un .gitattributes qui définit l'attribut texte pour les fichiers que je veux normaliser. Maintenant, lorsque je valide les changements, je reçois le message :

warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.

Comment puis-je faire en sorte que git normalise ma copie de travail du fichier pour moi ? De préférence, je voudrais que git normalise l'ensemble de l'arbre de travail.

Answer 1

Pour ceux qui utilisent la version 2.16 ou supérieure, vous pouvez simplement utiliser :

git add --renormalize .  # Update index with renormalized files
git status               # Show the files that will be normalized
git commit -m "Introduce end-of-line normalization"

Ces instructions sont directement issues du gitattributs . Pour les versions plus anciennes, le docs (antérieures à la v2.12) fournissent une réponse différente :

rm .git/index     # Remove the index to force git to
git reset         # re-scan the working directory
git status        # Show files that will be normalized
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Faites cette séquence après avoir édité .gitattributes .

Mise à jour

Il semble que certains utilisateurs aient eu des problèmes avec les instructions ci-dessus. Mise à jour de la documentation pour gitattributs (2.12 à 2.14) montre une nouvelle série d'instructions (après avoir modifié les fichiers .gitattributes) :

git read-tree --empty   # Clean index, force re-scan of working directory
git add .
git status        # Show files that will be normalized
git commit -m "Introduce end-of-line normalization"

Merci à @vossad01 pour avoir souligné ce point.

De plus, avec l'une ou l'autre solution, les fichiers de votre copie de travail conservent leurs anciennes fins de ligne. Si vous souhaitez les mettre à jour, assurez-vous que votre fichier l'arbre de travail est propre et l'utiliser :

git rm --cached -r .
git reset --hard

Maintenant les terminaisons de ligne seront correctes dans votre arbre de travail.

Answer 2

Avec le client Git 2.16 et les versions ultérieures, il existe désormais un moyen beaucoup plus simple de le faire. Il suffit d'utiliser :

git add --renormalize .

Note : il est préférable de faire cela avec un espace de travail propre. Pour plus de détails, voir :

• https://git-scm.com/docs/gitattributes#_end_of_line_conversion
• https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings

Answer 3

Approche alternative (ne diffère que par la commande utilisée)

Assurez-vous que vous n'avez pas de changements en attente dans le référentiel :

$ git status
$ git stash

Modifier .gitattributes donc l'interprétation des CRLF sera modifiée :

$ echo "*.txt  text" >>.gitattributes
$ git commit -m "Made .txt files a subject to CRLF normalization." -- .gitattributes

Supprime les données de l'index et rafraîchit le répertoire de travail :

$ git rm --cached -r .
$ git reset --hard

Examiner les corrections CRLF que Git propose :

$ git ls-files --eol
$ git status
$ git diff

D'accord avec la décision de Git :

$ git add -u
$ git commit -m "Normalized CRLF for .txt files"

Rechargez les changements comme si un clone propre avait été effectué :

$ git rm --cached -r .
$ git reset --hard

Answer 4

En .gitattributes n'affecteront que les nouveaux commits. Si ce référentiel a pas de publié (aucun autre ne dépendant de lui), vous pourriez vouloir parcourir tout l'historique. Sous Unix/Linux, vous pouvez utiliser dos2unix(1) pour réparer tous les fichiers en combinaison avec find(1) et en utilisant la réécriture de l'histoire de filter-branch (voir le discussion dans le livre git) vous pouvez même nettoyer l'historique complet du projet.

A utiliser avec le plus grand soin, sur un clone frais. Prenez contact avec quelqu'un qui pourraient avoir un clone, et les informer de ce que vous voulez faire.

Answer 5

L'option * text=auto dans .gitattributes laisse le dépôt Git dans un 'état illégal' s'il contient des fichiers avec des fins de ligne CRLF (Windows) qui sont maintenant marqués comme du texte (voir https://marc.info/?l=git&m=154484903528621&w=2 ). L'option standard de renormalisation ne fonctionne pas correctement avec les filtres LFS, donc les instructions dans les autres réponses ou par exemple à l'adresse suivante https://help.github.com/en/articles/dealing-with-line-endings ne fonctionnent pas correctement. Au lieu de cela, ces étapes ont fonctionné pour nous :

Situation :

• Sur Windows
• Le dépôt Git contenait des fichiers avec des fins de ligne CR et CRLF.
• Ajout de * text=auto à .gitattributes (pour ne pas dépendre du fait que l'utilisateur ait défini core.crlf=auto sous Windows)

• J'ai aussi changé le -crlf en -text pour les fichiers suivis par LFS, je ne suis pas sûr que ce soit nécessaire.

  1. Créer une nouvelle branche à partir de la branche avec la ligne se terminant par un problème (en supposant qu'il n'y a pas de changements non validés) : git checkout -b feature/doing-stuff-fix-eol
  2. Supprimer les filtres LFS de .gitattributes (remplacer tous les 'filter=lfs diff=lfs merge=lfs ' par rien)
  3. Commit et push : git commit -a -m "Désactiver les filtres LFS pour le correctif EOL".
  4. Déplacement vers un dossier non-git
  5. Désinstaller LFS globalement : git lfs uninstall
  6. Créer un nouveau clone du dépôt : git clone -b feature/doing-stuff-fix-eol [remote repository url] fix-eol
  7. Normaliser les fins de lignes : git add --renormalize . (notez le point pour renormaliser tous les fichiers)
  8. Vérifier seulement les bons fichiers normalisés. Il ne doit pas inclure les fichiers normalement traités par LFS !
  9. Commit et push (sauvegarder le hash) : git commit -m "Fixer les fins de lignes".
  10. Déplacement vers un dossier non-git
  11. Installer LFS globalement : git lfs install
  12. Allez au clone du dépôt d'origine et tirer
  13. Vérifiez votre branche originale : git checkout feature/doing-stuff
  14. Cherry pick the eol fix commit and push : git cherry-pick [hash]
  15. Supprimer la branche eol et pousser
  16. Supprimez le clone du dépôt eol (ou gardez-le si vous avez besoin de corriger d'autres branches).