Quelle est la stratégie pour gérer les CRLF (retour chariot, saut de ligne) avec Git ?

Question

J'ai essayé de commettre 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é amené à arrêter d'essayer d'utiliser Git et d'essayer plutôt Mercurial .

Comment gérer correctement les fins de ligne CRLF ?

Answer 1

Presque quatre ans après avoir posé cette question, j'ai finalement trouvé une réponse qui me satisfait pleinement !

Voir les détails dans github:help Le guide de la Gérer les fins de ligne .

Git vous permet de définir les propriétés de fin de ligne pour un repo directement en utilisant la commande attribut du texte i .gitattributes fichier. T le repo et remplace le fichier core.autocrlf la mise en place, vous permettant de garantir un comportement cohérent pour tous les utilisateurs, quels que soient leurs paramètres git.

Et ainsi

T de fin de ligne voyage maintenant avec votre référentiel et vous n'avez pas besoin de vous soucier de w ont 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 une collection de fichiers .gitattributes prêts à être utilisés pour les langages de programmation les plus courants. Il est utile pour vous aider à démarrer.

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

Notez que le Bureau GitHub L'application peut suggérer et créer un .gitattributes après avoir ouvert le dépôt Git de votre projet dans l'application. Pour essayer cela, cliquez sur l'icône de l'engrenage (dans le coin supérieur droit) > Paramètres du dépôt ... > Fin de ligne et attributs. Il vous sera demandé d'ajouter l'attribut recommandé .gitattributes et si vous acceptez, l'application effectuera également une normalisation de tous les fichiers de votre dépôt.

Enfin, le Attention à l'extrémité de votre ligne L'article fournit plus de contexte et explique comment Git a évolué sur les questions qui nous occupent. Je considère que lecture obligatoire .

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. Dans ce cas, vous n'avez pas de chance, comme l'explique @gatinueta 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, puisque ces outils ignoreront simplement les attributs .git et vérifieront joyeusement les fichiers CRLF. https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

Une astuce pourrait être de leur demander de valider leurs modifications dans un autre client, par exemple SourceTree . Notre équipe de l'époque préférait cet outil à EGit d'Eclipse pour de nombreux cas d'utilisation.

Qui a dit que les logiciels étaient faciles ? :-/

Answer 2

Ne pas convertir les fins de ligne. Ce n'est pas le rôle du VCS d'interpréter les données - il suffit de les stocker et de les mettre en version. Chaque éditeur de texte moderne peut lire les deux types de fin de ligne de toute façon.

Answer 3

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

Quelques éléments de contexte supplémentaires ci-dessous :

Il devrait être soit core.autocrlf=true si vous aimez la fin du DOS ou core.autocrlf=input i unix-newlines. Dans les deux cas, votre dépôt Git aura n'aura que LF, ce qui est la bonne chose. Le seul pour le de l'argument de l'option core.autocrlf=false w d'une heur heuristique automatique peut et alors votre tuile sera corrompue. [ ] core.safecrlf a été introduite pour un changement irréversible se produit. En fait, il y a deux possibilités de changements irréversibles -- mixte fin de ligne dans un fichier texte, dans ce cas la normalisation est souhaitable, donc cet avertissement peut être ignoré, ou bien (très peu probable) que Git ait mal détecté votre fichier fichier binaire comme du texte. Dans ce cas, vous devez utiliser des attributs pour indiquer à Git que ce fichier est binaire.

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

Answer 4

Deux stratégies alternatives pour devenir cohérent sur les fins de ligne dans des environnements mixtes (Microsoft + Linux + Mac) :

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

1. Convertir format tout en un

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

2. Définir core.autocrlf a input sur Linux/UNIX ou true sur MS Windows (référentiel ou global)

   git config --global core.autocrlf input

3. En option, vous pouvez définir core.safecrlf a true (pour arrêter) ou warn (to sing :) pour ajouter une garde supplémentaire en comparant si la transformation inversée des nouvelles lignes aboutirait au même fichier

   git config --global core.safecrlf true

B. Ou par configuration du référentiel

1. Convertir format tout en un

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

2. Ajouter un .gitattributes à 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 pour vos fichiers binaires - Git devrait être suffisamment intelligent à leur sujet.

---

En savoir plus sur les variables safecrlf/autocrlf

Answer 5

Essayez de régler le core.autocrlf option de configuration pour true . Jetez également un coup d'œil à la core.safecrlf option.

En fait, on dirait que core.safecrlf est peut-être déjà défini dans votre dépôt, 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 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 de simplement "utiliser ce qui vous est donné" et d'utiliser des lignes terminées par LF sous Windows causera plus de problèmes qu'elle n'en résoudra. Git dispose des options ci-dessus pour essayer de gérer les fins de ligne de manière raisonnable, il est donc logique de les utiliser.