J'ai essayé de valider des fichiers avec des lignes se terminant par 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é tenté d'arrêter d'utiliser Git et d'essayer Mercurial .

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

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

Voir les détails dans github: guide de l' aide pour gérer les fins de ligne .

Git vous permet de définir les propriétés de fin de ligne pour un dépôt directement à l'aide de l' attribut text du .gitattributesfichier. Ce fichier est validé dans le référentiel et remplace le core.autocrlfparamètre, ce qui vous permet d'assurer un comportement cohérent pour tous les utilisateurs, quels que soient leurs paramètres git.

Et ainsi

L'avantage de ceci est que votre configuration de fin de ligne voyage maintenant avec votre référentiel et vous n'avez pas à vous soucier de savoir si les collaborateurs ont ou non les paramètres globaux appropriés.

Voici un exemple de .gitattributesfichier

# 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 existe une collection pratique de fichiers .gitattributes prêts à l'emploi pour les langages de programmation les plus populaires. Il est utile de vous aider à démarrer.

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

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

Enfin, l'article Mind the End of Your Line fournit plus de contexte et explique comment Git a évolué sur les sujets traités. Je considère cette lecture nécessaire .

Vous avez probablement des utilisateurs dans votre équipe qui utilisent EGit ou JGit (des outils comme Eclipse et TeamCity les utilisent) pour valider leurs modifications. Ensuite, 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 archiveront volontiers les fichiers CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

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

Qui a dit que le logiciel était facile? : - /

Ne convertissez pas les fins de ligne. Ce n'est pas le travail du VCS d'interpréter les données - il suffit de les stocker et de les versionner. Tout éditeur de texte moderne peut de toute façon lire les deux types de fins de ligne.

Vous voulez presque toujours à autocrlf=inputmoins que vous sachiez vraiment ce que vous faites.

Un contexte supplémentaire ci-dessous:

Cela devrait être le cas core.autocrlf=truesi vous aimez terminer DOS ou core.autocrlf=inputsi vous préférez unix-newlines. Dans les deux cas, votre référentiel Git n'aura que LF, ce qui est la bonne chose. Le seul argument pour core.autocrlf=falseétait que l'heuristique automatique peut détecter de manière incorrecte certains binaires en tant que texte et que votre mosaïque sera corrompue. Ainsi, une core.safecrlfoption a été introduite pour avertir un utilisateur si un changement irréversible se produit. En fait, il existe deux possibilités de changements irréversibles - une fin de ligne mixte dans un fichier texte, dans cette normalisation est souhaitable, donc cet avertissement peut être ignoré, ou (très peu probable) que Git a incorrectement détecté votre fichier binaire en tant que texte. Ensuite, vous devez utiliser des attributs pour indiquer à Git que ce fichier est binaire.

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

Deux stratégies alternatives pour obtenir une cohérence sur les fins de ligne dans les environnements mixtes (Microsoft + Linux + Mac):

A. Global Configuration par tous les référentiels

1) Convertissez tout en un seul format

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

2) Mettre core.autocrlfà inputsous Linux / UNIX outrue sur MS Windows (dépôt ou global)

git config --global core.autocrlf input

3) [Facultatif] défini core.safecrlfsur true(pour arrêter) ou warn(pour chanter :) pour ajouter une garde supplémentaire en comparant si la transformation de nouvelle ligne inversée entraînerait le même fichier

git config --global core.safecrlf true

B. Ou par configuration de référentiel

1) Convertissez tout en un seul format

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

2) Ajoutez un .gitattributesfichier à votre référentiel

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

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

En savoir plus sur les variables safecrlf / autocrlf

Essayez de définir l' core.autocrlfoption de configuration sur true. Jetez également un œil à l' core.safecrlfoption.

En fait, il semble que vous core.safecrlfayez déjà été défini dans votre référentiel, car (c'est moi qui souligne):

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

Si tel est le cas, vous voudrez peut-être 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 de simplement "utiliser ce qu'on vous donne" et d'utiliser des lignes terminées LF sous 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 de manière sensée, il est donc logique de les utiliser.

L'utilisation a core.autocrlf=falseempêché tous les fichiers d'être marqués comme mis à jour dès que je les ai extraits dans mon Visual Studio 2010 projet . Les deux autres membres de l'équipe de développement utilisent également des systèmes Windows, donc un environnement mixte n'est pas entré en jeu, mais les paramètres par défaut fournis avec le référentiel marquaient toujours 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 de nombreux autres référentiels sur nos boîtes Linux, le réglage autocrlf = trueproduit de meilleurs résultats.

Plus de 20 ans plus tard et nous avons toujours affaire à des disparités de fin de ligne entre les systèmes d'exploitation ... triste.

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

* text = auto

Dans le .gitattributesfichier de votre référentiel, ajoutez:

*   text=auto

Cela normalisera tous les fichiers avec des LFfins de ligne dans le référentiel.

Et selon votre système d'exploitation ( core.eolparamètre), les fichiers de l'arborescence de travail seront normalisés LFpour les systèmes basés sur Unix ou CRLFpour les systèmes Windows.

Il s'agit de la configuration utilisée par les référentiels Microsoft .NET .

Exemple:

Hello\r\nWorld

Sera normalisé dans le repo toujours comme:

Hello\nWorld

Au moment du paiement, l'arborescence de travail de Windows sera convertie en:

Hello\r\nWorld

Lors du paiement, l'arborescence de travail dans Mac sera laissée comme:

Hello\nWorld

Remarque: Si votre dépôt contient déjà des fichiers non normalisés, git statusces fichiers seront complètement modifiés la prochaine fois que vous y apporterez des modifications, et il pourrait être difficile pour d'autres utilisateurs de fusionner leurs modifications plus tard. Consultez l' actualisation d'un référentiel après avoir modifié les fins de ligne pour plus d'informations.

core.autocrlf = true

Si textn'est pas spécifié dans le .gitattributesfichier, Git utilise lecore.autocrlf variable de configuration pour déterminer si le fichier doit être converti.

Pour les utilisateurs de Windows, git config --global core.autocrlf truec'est une excellente option car:

• Les fichiers sont normalisés aux LFfins de ligne uniquement lorsqu'ils sont ajoutés au référentiel. S'il y a des fichiers non normalisés dans le référentiel, ce paramètre ne les touchera pas.
• Tous les fichiers texte sont convertis en CRLFfins de ligne dans le répertoire de travail.

Le problème avec cette approche est que:

• Si vous êtes un utilisateur de Windows autocrlf = input, vous verrez un tas de fichiers avec des LFfins de ligne. Pas un danger pour le reste de l'équipe, car vos commits seront toujours normalisés avec des LFfins de ligne.
• Si vous êtes un utilisateur de Windows core.autocrlf = false, vous verrez un tas de fichiers avec des LFfins de ligne et vous pouvez introduire des fichiers avec des CRLFfins de ligne dans le référentiel.
• La plupart des utilisateurs de Mac utilisent autocrlf = inputet peuvent obtenir des fichiers avec CRLFdes fins de fichier, probablement des utilisateurs de Windows avec core.autocrlf = false.

--- UPDATE 3 --- (n'entre pas en conflit avec UPDATE 2)

Étant donné que les utilisateurs de Windows préfèrent travailler sur CRLFet les utilisateurs de Linux / Mac préfèrent travailler sur des LFfichiers texte. Fournir la réponse du point de vue d'un mainteneur de référentiel :

Pour moi, la meilleure stratégie (moins de problèmes à résoudre) est de conserver tous les fichiers texte avec LFgit repo à l' intérieur même si vous travaillez sur un projet Windows uniquement. Ensuite, donnez aux clients la liberté de travailler sur le style de fin de ligne de leur préférence , à condition qu'ils choisissent une core.autocrlfvaleur de propriété qui respectera votre stratégie (LF au dépôt) tout en préparant les fichiers à valider.

La mise en scène est ce que beaucoup de gens confondent lorsqu'ils essaient de comprendre comment fonctionnent les stratégies de nouvelle ligne . Il est essentiel de comprendre les points suivants avant de choisir la valeur correcte pour la core.autocrlfpropriété:

• Ajout d' un fichier texte pour Commit ( mise en scène il) est comme la copie du fichier à un autre endroit dans le .git/sous-répertoire avec fins de ligne convertis ( en fonction de la core.autocrlfvaleur de votre configuration client). Tout cela se fait localement.
• paramètre core.autocrlfest comme fournir une réponse à la question (exactement la même question sur tous les OS):
  • "Doit git-client a. Convertir LF-en-CRLF lors de l'extraction (tirer) le repo change de la télécommande ou b. Convertir CRLF-en-LF lors de l'ajout d'un fichier à valider? " Et les réponses possibles (valeurs) sont:
  • false:" ne faites rien de ce qui précède ",
  • input:" faire seulement b "
  • true: " faire a et b "
  • notez qu'il n'y a PAS de " ne faire qu'un "

Heureusement

• Les valeurs par défaut du client git (windows core.autocrlf: true:, linux / mac:) core.autocrlf: falseseront compatibles avec la stratégie LF-only-repo .
  Signification : les clients Windows seront par défaut convertis en CRLF lors de l'extraction du référentiel et convertis en LF lors de l'ajout pour validation. Et les clients Linux ne feront par défaut aucune conversion. Ceci conserve théoriquement votre dépôt uniquement.

Malheureusement:

• Il peut y avoir des clients GUI qui ne respectent pas la core.autocrlfvaleur git
• Il peut y avoir des gens qui n'utilisent pas de valeur pour respecter votre stratégie de lf-repo. Par exemple, ils utilisent core.autocrlf=falseet ajoutent un fichier avec CRLF pour la validation.

Pour détecter les fichiers texte non lf ASAP commis par les clients ci-dessus, vous pouvez suivre ce qui est décrit sur --- mise à jour 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, sur un client compilé en utilisant: --with-libpcreflag)

Et est le piège ici: . En tant que mainteneur de pension, je gardegit.autocrlf=input afin de pouvoir corriger tous les fichiers mal validés simplement en les ajoutant à nouveau pour la validation. Et je fournis un texte de validation: "Correction des fichiers mal validés".

Autant .gitattributesqu'on le comprend. Je ne compte pas là-dessus, car il y a plus de clients ui qui ne le comprennent pas. Je ne l'utilise que pour fournir des conseils pour le texte et les fichiers binaires, et peut-être signaler certains fichiers exceptionnels qui devraient partout garder les mêmes fins de ligne:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Question: Mais pourquoi sommes-nous intéressés par la stratégie de gestion de la nouvelle ligne?

Réponse: pour éviter une validation de modification d' une seule lettre, apparaissez comme une modification de 5000 lignes , simplement parce que le client qui a effectué la modification a automatiquement converti le fichier complet de crlf en lf (ou l'inverse) avant de l'ajouter pour la validation. Cela peut être assez douloureux en cas de résolution de conflit . Ou cela pourrait dans certains cas être la cause de conflits déraisonnables.

--- MISE À JOUR 2 ---

Les dafaults de git client fonctionneront dans la plupart des cas. Même si vous n'avez que des clients Windows uniquement, des clients Linux uniquement ou les deux. Ceux-ci sont:

• Windows: core.autocrlf=true signifie convertir les lignes en CRLF à la caisse et convertir les lignes en LF lors de l'ajout de fichiers.
• linux: core.autocrlf=input signifie ne pas convertir les lignes à la caisse (pas besoin car les fichiers devraient être validés avec LF) et convertir les lignes en LF (si nécessaire) lors de l'ajout de fichiers. ( - update3 - : Il semble que ce soit falsepar défaut, mais encore une fois, ça va)

La propriété peut être définie dans différentes étendues. Je suggère de définir explicitement la --globalportée, pour éviter certains problèmes IDE décrits à la fin.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Je déconseille également fortement l' utilisation sur Windows git config --global core.autocrlf false (au cas où vous avez uniquement des clients Windows) contrairement à ce qui est proposé pour la documentation Git . La valeur false va valider les fichiers avec CRLF dans le référentiel. Mais il n'y a vraiment aucune raison. Vous ne savez jamais si vous devrez partager le projet avec des utilisateurs Linux. De plus, c'est une étape supplémentaire pour chaque client qui rejoint le projet au lieu d'utiliser les valeurs par défaut.

Maintenant, pour certains cas particuliers de fichiers (par exemple *.bat *.sh) dont vous souhaitez qu'ils soient extraits avec LF ou avec CRLF, vous pouvez utiliser.gitattributes

Pour résumer, la meilleure pratique est:

• Assurez-vous que chaque fichier non binaire est validé avec LF sur git repo (comportement par défaut).
• Utilisez cette commande pour vous assurer qu'aucun fichier n'est validé avec CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Remarque: sur les clients Windows ne fonctionne que via git-bashet sur les clients Linux uniquement s'ils sont compilés à l'aide de --with-libpcrein ./configure).
• Si vous trouvez de tels fichiers en exécutant la commande ci-dessus, corrigez-les. Cela implique (au moins sur Linux):
  • définir core.autocrlf=input( --- mise à jour 3 - )
  • changer le fichier
  • annuler la modification (le fichier est toujours affiché comme modifié)
  • engagez-le
• N'utilisez que le strict minimum .gitattributes
• Demandez aux utilisateurs de définir ce qui est core.autocrlfdécrit ci-dessus sur ses valeurs par défaut.
• Ne comptez pas à 100% sur la présence de .gitattributes. Les clients git des IDE peuvent les ignorer ou les traiter différemment.

Comme dit, certaines choses peuvent être ajoutées dans les attributs git:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Je pense que d'autres options sûres pour .gitattributesau lieu d'utiliser la détection automatique pour les fichiers binaires:

• -text(par exemple pour *.zipou *.jpgfichiers: ne sera pas traité comme du texte. Par conséquent, aucune conversion de fin de ligne ne sera tentée. Des différences pourraient être possibles grâce aux programmes de conversion)
• text !eol(par exemple *.java, *.html:. Donc paramètre client est utilisé traité comme du texte, mais la préférence de style EOL n'est pas réglé.)
• -text -diff -merge(par exemple pour *.hugefile: Non traité comme du texte. Aucune différence / fusion possible)

--- MISE À JOUR PRÉCÉDENTE ---

Un exemple douloureux d'un client qui commettra des fichiers à tort:

netbeans 8.2 (sous Windows), commettra à tort tous les fichiers texte avec des CRLF, sauf si vous l'avez explicitement défini core.autocrlfcomme global . Cela contredit le comportement standard du client git et cause beaucoup de problèmes plus tard lors de la mise à jour / fusion. C'est ce qui rend certains fichiers différents (bien qu'ils ne le soient pas) même lorsque vous revenez .
Le même comportement dans les netbeans se produit même si vous avez ajouté correctement.gitattributes à votre projet.

L'utilisation de la commande suivante après un commit vous aidera au moins à détecter tôt si votre dépôt git a des problèmes de fin de ligne: git grep -I --files-with-matches --perl-regexp '\r' HEAD

J'ai passé des heures à trouver la meilleure utilisation possible .gitattributes, pour enfin réaliser que je ne peux pas compter là-dessus.
Malheureusement, tant qu'il existe des éditeurs basés sur JGit (qui ne peuvent pas gérer .gitattributescorrectement), la solution sûre est de forcer LF partout même au niveau de l'éditeur.

Utilisez les anti-CRLFdésinfectants suivants .

• clients windows / linux: core.autocrlf=input

• engagé .gitattributes: * text=auto eol=lf

• commis .editorconfig( http://editorconfig.org/ ) qui est une sorte de format standardisé, combiné avec des plugins d'éditeur:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Ceci est juste une solution de contournement :

Dans des cas normaux, utilisez les solutions fournies avec git. Ceux-ci fonctionnent très bien dans la plupart des cas. Forcer à LF si vous partagez le développement sur les systèmes Windows et Unix en définissant .gitattributes .

Dans mon cas, il y avait> 10 programmeurs développant un projet sous Windows. Ce projet a été enregistré avec CRLF et il n'y avait aucune option pour forcer à LF.

Certains paramètres ont été écrits en interne sur ma machine sans aucune influence sur le format LF; ainsi, certains fichiers ont été globalement modifiés en LF à chaque changement de petit fichier.

Ma solution:

Windows-Machines: laissez tout tel quel. Ne vous souciez de rien, car vous êtes un développeur par défaut de «loup solitaire» et que vous devez gérer comme ceci: «Il n'y a pas d'autre système dans le monde entier, n'est-ce pas?

Unix-Machines

1. Ajoutez les lignes suivantes à la [alias]section d' une configuration . Cette commande répertorie tous les fichiers modifiés (c'est-à-dire modifiés / nouveaux):

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Convertissez tous ces fichiers modifiés au format DOS:

   unix2dos $(git lc)

3. En option ...

   1. Créez un crochet git pour cette action afin d'automatiser ce processus

   2. Utilisez des paramètres et incluez-le et modifiez la grepfonction pour qu'elle ne corresponde qu'à des noms de fichiers particuliers, par exemple:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. N'hésitez pas à le rendre encore plus pratique en utilisant un raccourci supplémentaire:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... et lancez le contenu converti en tapant

      git c2dos