Question Quelle est la meilleure stratégie de gestion CRLF (retour chariot, saut de ligne) avec Git?


J'ai essayé de valider des fichiers avec des lignes de fin de fichier CRLF, mais cela a échoué.

J'ai passé toute une journée de travail sur mon ordinateur Windows à essayer différentes stratégies et j'ai presque été attiré pour arrêter d'essayer Git et essayer Mercuriel.

Veuillez ne partager qu'une seule bonne pratique par réponse.


543
2017-10-04 20:39


origine


Réponses:


Près de quatre ans après avoir posé cette question, j'ai finalement a trouvé une réponse qui me satisfait complètement!

Voir les détails dans github: aideGuide de Traiter les fins de ligne.

Git vous permet de définir les propriétés de fin de ligne pour un   repo directement en utilisant le attribut de texte dans le    .gitattributes fichier. Ce fichier est engagé dans   le repo et remplace le core.autocrlf réglage,   vous permettant d'assurer un comportement cohérent pour tous   utilisateurs indépendamment de leurs paramètres git.

Et ainsi

L'avantage de ceci est que votre fin de ligne   configuration se déplace maintenant avec votre référentiel et vous   ne pas avoir à se soucier de savoir si oui ou non les collaborateurs   avoir les paramètres globaux appropriés.

Voici un exemple de .gitattributes fichier

# 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

Il y a un pratique collection de fichiers .gitattributes prêts à l'emploi pour les langages de programmation les plus populaires. C'est utile pour vous aider à démarrer.

Une fois que vous avez créé ou ajusté votre .gitattributes, vous devriez effectuer une fois pour toutes re-normalisation des fins de ligne.

Notez que le GitHub Desktop application peut suggérer et créer un .gitattributes fichier après avoir ouvert le repo Git de votre projet dans l'application. Pour essayer cela, cliquez sur l'icône d'engrenage (dans le coin supérieur droit)> Paramètres du référentiel ...> Terminaisons de ligne et attributs. Il vous sera demandé d'ajouter les recommandations .gitattributes et si vous êtes d'accord, l'application effectuera également une normalisation de tous les fichiers de votre référentiel.

Finalement, le Attention à la fin de votre ligne article fournit plus de contexte et explique comment Git a évolué sur les questions en cours. Je considère ceci lecture obligatoire.

Vous avez probablement des utilisateurs de votre équipe qui utilisent EGit ou JGit (des outils comme Eclipse et TeamCity les utilisent) pour valider leurs modifications. Alors vous n'avez pas de chance, comme @gatinueta l'a expliqué dans les commentaires de cette réponse:

Ce paramètre ne vous satisfera pas complètement si vous avez des personnes travaillant avec Egit ou JGit dans votre équipe, car ces outils ignoreront simplement .gitattributes et vérifieront avec bonheur les fichiers CRLF. https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

Une astuce pourrait être de les faire commettre leurs changements dans un autre client, disons SourceTree. Notre équipe a alors préféré cet outil à l'EGit d'Eclipse pour de nombreux cas d'utilisation.

Qui a dit que le logiciel est facile? : - /


683
2018-06-01 18:56



Ne pas convertir les fins de ligne. Le travail du VCS n'est pas d'interpréter les données - il suffit de les stocker et de les mettre à jour. Chaque éditeur de texte moderne peut lire les deux types de fin de ligne de toute façon.


98
2017-10-04 20:42



Vous avez presque toujours envie autocrlf=input à moins que vous ne sachiez vraiment ce que vous faites.

Un contexte supplémentaire ci-dessous:

Cela devrait être soit core.autocrlf=true si tu veux   Terminaison DOS ou core.autocrlf=input si tu préfères   Unix-Newlines. Dans les deux cas, votre référentiel Git   avoir seulement LF, ce qui est la bonne chose. Le seul   argument pour core.autocrlf=false était-ce automatique   heuristique peut détecter de manière incorrecte certains binaires en tant que texte   et alors votre tuile sera corrompue. Alors,    core.safecrlf option a été introduite pour avertir un utilisateur si   un changement irréversible arrive. En fait, il y a deux   possibilités de changements irréversibles - mixte   la fin de la ligne dans le fichier texte, dans cette normalisation est   souhaitable, de sorte que cet avertissement peut être ignoré, ou   (très peu probable) que Git a détecté votre   fichier binaire comme texte. Ensuite, vous devez utiliser des attributs pour   dis à Git que ce fichier est binaire.

Le paragraphe ci-dessus a été tiré d'un fil de discussion sur gmane.org, mais il a disparu depuis.


76
2017-07-10 22:36



Deux stratégies alternatives à être cohérent à propos des fins de ligne dans des environnements mixtes (Microsoft + Linux + Mac):

A. Global par configuration de tous les référentiels

1) Convertir tous à un format

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

2) Set core.autocrlf à input sous Linux / UNIX ou true sur MS Windowns (référentiel ou global)

git config --global core.autocrlf input

3) [Option] core.safecrlf à true (pour arrêter) ou warn (chanter :) ajouter une garde supplémentaire si la transformation de retour à la ligne inversée aboutit au même fichier

git config --global core.safecrlf true


B. Ou par configuration du référentiel

1) Convertir tous à un format

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

2) ajouter .gitattributes déposer dans votre dépôt

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

Ne vous inquiétez pas de vos fichiers binaires - Git devrait être assez intelligent à leur sujet.


Plus d'informations sur les variables safecrlf / autocrlf


53
2018-06-26 01:18



Essayez de définir le core.autocrlf option de configuration à true. Regardez aussi le core.safecrlf option.

En fait, cela ressemble à core.safecrlf peut-être déjà défini dans votre référentiel, car (soulignement le mien):

Si ce n'est pas le cas pour le paramètre actuel de core.autocrlf, git va rejeter le fichier.

Si c'est le cas, vous pouvez vérifier que votre éditeur de texte est configuré pour utiliser les fins de ligne de manière cohérente. Vous rencontrerez probablement des problèmes si un fichier texte contient un mélange de fins de ligne LF et CRLF.

Enfin, je pense que la recommandation d'utiliser simplement ce que l'on vous a donné et d'utiliser des lignes terminées par LF sur Windows causera plus de problèmes qu'elle n'en résout. Git a les options ci-dessus pour essayer de gérer les fins de ligne d'une manière sensée, il est donc logique de les utiliser.


11
2017-10-05 03:50



En utilisant core.autocrlf=false arrêté tous les fichiers d'être marqué mis à jour dès que je les ai vérifié dans mon Visual Studio 2010 projet. Les deux autres membres de l'équipe de développement utilisent également des systèmes Windows, de sorte qu'un environnement mixte n'est pas entré en jeu, mais les paramètres par défaut fournis avec le référentiel ont toujours marqué tous les fichiers comme mis à jour immédiatement après le clonage.

Je suppose que l'essentiel est de trouver quel paramètre CRLF fonctionne pour votre environnement. D'autant plus que dans beaucoup d'autres dépôts sur notre configuration de boîtes Linux autocrlf = trueproduit de meilleurs résultats.

Plus de 20 ans plus tard et nous sommes toujours confrontés à des disparités de fin de ligne entre les OS ... triste.


9
2018-03-16 03:10



Ce sont les deux options pour les fenêtres et Visual Studio les utilisateurs qui partagent du code avec Mac ou Linux utilisateurs. Pour une explication détaillée, lisez le gitattributes manuel.

* texte = auto

Dans votre repo .gitattributes fichier ajouter:

*   text=auto

Cela va normaliser tous les fichiers avec LF fin de ligne dans le repo.

Et en fonction de votre système d'exploitation (core.eol réglage), les fichiers de l'arbre de travail seront normalisés LF pour les systèmes basés sur Unix ou CRLF pour les systèmes Windows.

C'est la configuration qui Microsoft .NET utilisation de repos.

Exemple:

Hello\r\nWorld

Sera normalisé dans le repo toujours comme:

Hello\nWorld

À la caisse, l'arbre de travail dans Windows sera converti en:

Hello\r\nWorld

À la caisse, l'arbre de travail dans Mac sera laissé comme:

Hello\nWorld

Remarque: Si votre dépôt contient déjà des fichiers non normalisés, git status affichera ces fichiers comme étant complètement modifiés la prochaine fois que vous y apporterez des modifications, et les autres utilisateurs pourraient avoir du mal à fusionner leurs modifications plus tard. Voir rafraîchir un dépôt après avoir changé les fins de ligne pour plus d'informations.

core.autocrlf = true

Si text est non spécifié dans le .gitattributes fichier, Git utilise le core.autocrlf variable de configuration pour déterminer si le fichier doit être converti.

Pour les utilisateurs de Windows, git config --global core.autocrlf true est une excellente option parce que:

  • Les fichiers sont normalisés pour LF fin de ligne seulement quand ajouté au repo. S'il y a des fichiers non normalisés dans le repo, ce paramètre ne les touchera pas.
  • Tous les fichiers texte sont convertis en CRLF fin de ligne dans le répertoire de travail.

Le problème avec cette approche est que:

  • Si vous êtes un utilisateur Windows avec autocrlf = input, vous verrez un tas de fichiers avec LF les fins de ligne. Pas de danger pour le reste de l'équipe, car vos commits seront toujours normalisés avec LF les fins de ligne.
  • Si vous êtes un utilisateur Windows avec core.autocrlf = false, vous verrez un tas de fichiers avec LF fin de ligne et vous pouvez introduire des fichiers avec CRLF fin de ligne dans le repo.
  • La plupart des utilisateurs de Mac utilisent autocrlf = input et peut obtenir des fichiers avec CRLF fin de fichier, probablement des utilisateurs de Windows avec core.autocrlf = false.

5
2018-02-14 23:02