2009-08-08 3 views
36

J'installe msysgit 1.6.4 beta sur mon VPC de développement Win Vista. Un écran d'installation demande si je souhaite utiliser la terminaison de ligne Unix ou la terminaison de ligne DOS. D'habitude, je choisirais DOS, mais le texte d'installation indique que la terminaison DOS peut signifier que les fichiers ne fonctionnent pas avec tous les outils de ligne de commande de Git. La terminaison de ligne Unix indique "... la plupart des applications [Windows] peuvent gérer cela ...".Git 1.6.4 beta sous Windows (msysgit) - Terminaison de ligne Unix ou DOS

Est-ce que quelqu'un sait quelle option je devrais choisir pour utiliser Git via le shell pour mon travail VS 2008? Visual Studio 2008 gère Unix Terminaisons de ligne sans problème.

Répondre

106

Que les paramètres lors du processus d'installation de msysgit est réellement ici pour fixer la valeur de core.autocrlfconfig.

core.autocrlf 

Si cela est vrai, fait convertir git CRLF à la fin des lignes dans des fichiers texte à LF lors de la lecture du système de fichiers, et convertir en sens inverse lors de l'écriture au système de fichiers. La variable peut être définie sur 'input', auquel cas la conversion se produit uniquement lors de la lecture du système de fichiers, mais les fichiers sont écrits avec LF à la fin des lignes. Actuellement, les chemins à considérer comme "texte" (c'est-à-dire être soumis au mécanisme d'autocrlf) sont décidés uniquement en fonction du contenu.

j'insister sur pas essayer de convertir quoi que ce soit automagiquement, les effets secondaires sont trop importants (en terme de conflit fusion potentiel, en particulier sur le développement distribué avec des environnements différents)

Si vos outils peut gérer la terminaison de ligne Unix, vous devez les configurer pour produire des lignes Unix, qui peuvent ensuite être lues par Windows (VS2008, Notepad ++, ...) et Unix, et peuvent être traitées par tous les scripts Git 'sh'.

Mais avec core.autocrlf mis à false, la décision de transformer une terminaison de ligne de texte sera une décision explicite volontaire, et non une arrière-plan invisible.


Voir plus à "How line ending conversions work with git core.autocrlf between different operating systems"

 
       | Resulting conversion when  | Resulting conversion when 
       | committing files with various | checking out FROM repo - 
       | EOLs INTO repo and    | with mixed files in it and 
       | core.autocrlf value:   | core.autocrlf value:   
-------------------------------------------------------------------------------- 
File    | true  | input  | false | true  | input | false 
-------------------------------------------------------------------------------- 
Windows-CRLF  | CRLF -> LF | CRLF -> LF | as-is | as-is  | as-is | as-is 
Unix -LF   | as-is  | as-is  | as-is | LF -> CRLF | as-is | as-is 
Mac -CR   | as-is  | as-is  | as-is | as-is  | as-is | as-is 
Mixed-CRLF+LF | as-is  | as-is  | as-is | as-is  | as-is | as-is 
Mixed-CRLF+LF+CR | as-is  | as-is  | as-is | as-is  | as-is | as-is 

+0

Merci! Je vais de l'avant avec la terminaison de ligne Unix. –

+0

Je ne vois pas comment vous pouvez obtenir un conflit de fusion basé sur les fins de ligne. Dans le cas où vous avez autocrlf True, si vous récupérez localement quelqu'un qui a CRLF, les fins ne seraient-elles pas converties en LF (avant la fusion)? (Vous auriez également n'importe quel CRLF converti en LF si vous venez de pousser localement) – RJFalconer

+0

@BlueNovember: le raisonnement est que vous ne pouvez pas garantir que chaque paramètre dans chaque environnement a ce paramètre correctement défini. Même si vous ne rencontrez pas de conflit dans votre environnement, vous risquez de provoquer des problèmes insoupçonnés dans d'autres clients Git distants. – VonC

2

Cependant, il tentera de détecter les fichiers texte avec des terminaisons de ligne incohérentes dans le but de les corriger. Bloc-notes, d'autre part n'est pas en mesure d'afficher correctement Unix fichiers texte.

+35

Espérons que la compatibilité du Bloc-notes n'est pas une exigence importante. –

+0

Non, la compatibilité avec le Bloc-notes n'est pas un problème. On dirait que la terminaison Unix est le meilleur choix. Je vous remercie! –

+9

Notepad ++ fonctionne parfaitement avec les deux styles de terminaison de ligne. – alexandrul