web-dev-qa-db-fra.com

Comment normaliser les fins de ligne d'arbre de travail dans Git?

J'ai cloné un référentiel qui avait des fins de ligne incohérentes. J'ai ajouté un .gitattributes qui définit l'attribut de texte pour les fichiers que je souhaite normaliser. Maintenant, lorsque je valide des modifications, 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 git normaliser ma copie de travail du fichier pour moi? De préférence, je voudrais que git normalise tout l'arbre de travail.

gitline-endingsgitattributes
54
user11171

Avec Git client 2.16 et supérieur, il existe désormais un moyen beaucoup plus simple de le faire. Utilisez simplement git add --renormalize .

60
philippn

Pour ceux qui utilisent la v2.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 directions sont tout droit sorties des gitattributes . Pour les versions plus anciennes, les docs (avant 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"

Effectuez cette séquence après avoir modifié .gitattributes.

Mise à jour

Il semble que certains utilisateurs aient eu des problèmes avec les instructions ci-dessus. La documentation mise à jour pour gitattributes (2.12 à 2.14) montre un nouvel ensemble d'instructions (après avoir édité 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 l'avoir signalé.

De plus, avec les deux solutions, les fichiers de votre copie de travail conservent toujours leurs anciennes fins de ligne. Si vous souhaitez les mettre à jour, assurez-vous que votre arborescence de travail est propre et utilisez:

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

Maintenant, les fins de ligne seront correctes dans votre arbre de travail.

82
John Szakmeister

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

Assurez-vous que vous n'avez aucune modification en attente dans le référentiel:

$ git status
$ git stash

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

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

Supprimez les données de l'index et actualisez le répertoire de travail:

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

Examinez les correctifs CRLF proposés par Git:

$ 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 modifications comme si un clone propre avait été effectué:

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

Les paramètres .gitattributes N'affecteront que les nouveaux validations. Si ce référentiel n'a aucun historique publié (aucun autre en fonction), vous voudrez peut-être parcourir tout l'historique. Sous Unix/Linux, vous pouvez utiliser dos2unix(1) pour corriger tous les fichiers en combinaison avec find(1), et en utilisant la réécriture de l'historique de filter-branch (Voir discussion dans le git book), vous pouvez même nettoyer l'historique complet du projet.

A utiliser avec le plus grand soin, sur un clone frais. Entrez en contact avec toute personne qui pourrait avoir un clone, et dites-lui ce que vous voulez faire.

4
vonbrand

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

Situation:

  • Sous Windows
  • Le référentiel Git contenait des fichiers avec les fins de ligne CR et CRLF
  • * Text = auto ajouté à .gitattributes (donc ne dépend pas de l'utilisateur ayant défini core.crlf = auto sous Windows)

  • A également changé le -crlf en -text pour les fichiers suivis LFS, pas sûr que ce soit nécessaire.

    1. Créez une nouvelle branche à partir de la branche avec le problème de fin de ligne (en supposant qu'il n'y ait aucun changement non engagé): git checkout -b feature/doing-stuff-fix-eol
    2. Supprimez les filtres LFS de .gitattributes (remplacez tout 'filter = lfs diff = lfs merge = lfs' par rien)
    3. Valider et pousser: git commit -a -m "Désactiver les filtres LFS pour le correctif EOL"
    4. Déplacer vers un dossier non git
    5. Désinstaller LFS globalement: désinstallation de git lfs
    6. Créer un nouveau clone de référentiel: git clone -b feature/doing-stuff-fix-eol [URL de référentiel distant] fix-eol
    7. Normaliser les fins de ligne: git add --renormalize. (notez le point pour renormaliser tous les fichiers)
    8. Vérifiez uniquement les fichiers corrects normalisés. Il ne doit pas inclure de fichiers normalement gérés par LFS!
    9. Valider et pousser (enregistrer le hachage): git commit -m "Fix line endings"
    10. Déplacer vers un dossier non git
    11. Installer LFS globalement: git lfs install
    12. Accédez au clone du référentiel d'origine et tirez
    13. Commander votre branche d'origine: fonctionnalité de git checkout/faire des choses
    14. Cherry pick le correctif eol et push: git cherry-pick [hash]
    15. Supprimer la branche eol et pousser
    16. Supprimez le clone du référentiel eol (ou restez si vous avez besoin de réparer plus de branches)
0
Walter Laan