Les trois valeurs de autocrlf:
true - lorsque le contenu va dans le référentiel (est engagé), ses fins de ligne seront convertis en LF, et lorsque le contenu provient de l'référentiel (extrait), les fins de ligne être converti à CRLF. C'est en général destinée pour les désemparés, les utilisateurs de windows/éditeurs. Compte tenu de l'hypothèse qu'un éditeur (ou l'utilisateur) va créer des fichiers avec CRLF à la fin, et va paniquer si il voit normale LF terminaisons, mais que vous souhaitez LF terminaisons dans le repo, cela devrait vous couvrir. Il est possible que les choses aillent mal, cependant. Il y a des exemples de fausses fusion des conflits et des rapports de fichiers modifiés dans les liens de questions.
input - lorsque le contenu va dans le référentiel, ses fins de ligne seront convertis en LF, mais le contenu est laissé intact sur le moyen de sortir. C'est essentiellement dans le même royaume que true, avec l'hypothèse que les éditeurs peuvent en fait faire face avec LF terminaisons correctement; vous êtes juste à la protection contre la possibilité de créer accidentellement un fichier avec CRLF terminaisons.
false - git n'a pas affaire à des fins de ligne. C'est à vous. C'est ce que beaucoup de gens recommandent. Avec ce réglage, si un fichier de fins de ligne sont va être sali avec, vous devez être au courant de cela, de sorte que les conflits de fusion sont beaucoup moins susceptibles (en supposant que l'utilisateur averti). La formation des développeurs sur la façon d'utiliser leurs éditeurs/IDEs pouvez très bien prendre en charge le problème. Tous les éditeurs que j'ai vu conçu pour les programmeurs sont capables de faire face à cette si configuré correctement.
Notez que autocrlf n'affectera pas le contenu qui est déjà dans le référentiel. Si vous avez commis quelque chose avec CRLF terminaisons précédemment, ils vont rester de cette façon. C'est une très bonne raison de ne pas dépendre de autocrlf; si un utilisateur ne l'a pas mis, ils peuvent obtenir du contenu avec CRLF terminaisons dans le repo, et il va rester dans les parages. Une plus forte manière, à force de normalisation est avec l' attribut de texte; le paramètre auto pour un chemin donné va marquer la fin de la ligne de la normalisation, en supposant que git décide le contenu est du texte (non binaire).
Une option possible est - safecrlf, ce qui est fondamentalement juste un façon de vous assurer de ne pas irreversably effectuer CRLF la conversion d'un fichier binaire.
Je n'ai pas une tonne d'expérience avec Windows questions et git, donc la rétroaction au sujet des implications/pièges est certainement la bienvenue.
