est-il possible de demander à GIT d'utiliser le CRLF au lieu de simplement à la fin des lignes qu'il met dans un fichier lorsqu'il a besoin de fusionner?
Si vous résolvez les conflits dans un éditeur de texte sans caractères EOL visibles, il est facile de se retrouver accidentellement avec ces LFS se faire fusionné si vous supprimez par sélection:
vous laissant avec:
Et maintenant deux LF ont se faufiler dans votre fichier Seron CRLF!
Évidemment, une alternative consiste à prendre plus de soins sur des fins de la ligne lors de la résolution des fonts, mais je pensais demander que je demanderais au cas où il y avait un moyen de dire à Git d'utiliser CRLF pour les lignes qu'elle génère ici.
3 Réponses :
Je ne suis pas sûr que s'il y a un moyen global de le faire, mais vous pouvez définir le caractère EOL par défaut pour chaque extension de fichier dans le fichier .gitattributes (voir la section de conversion de fin de ligne du gitattributes docs .
Par exemple, modifiez le fichier .gitattributes dans La racine du projet GIT afin qu'elle contienne quelque chose comme ceci:
Dans mes expériences, cela a fonctionné, mais il a eu le méchant effet secondaire de réécrire le contenu du fichier aux fins de la ligne UNIX lorsqu'elles ont été commises. Savez-vous un moyen d'éviter cela?
Il n'y a pas de paramètre qui contrôle les terminaisons de ligne utilisées pour les marqueurs "<<<<" dans GIT; Ils sont codés en dur pour utiliser Si vous définissez le " Ceci n'est probablement pas ce que vous voulez sur un projet .NET comme l'exemple ci-dessus.
Donc, je n'ai pas de bonne réponse pour vous, désolé. '\ n' dans le code source GIT (voir eol " ou " core.eol " paramètres sur " crlf ", puis ", puis", puis le "<<<< "Les marqueurs auront \ r \ n terminaisons dans le fichier (cela se produit pendant l'étape du filtre de la maculée / nettoyage, après le code lié ci-dessus), mais cela a un effet secondaire majeur: les fichiers vont Soyez «normalisé» sur leur chemin dans le référentiel, vous engagerez donc des fichiers avec des terminaisons de ligne UNIX.
Merci de relier le code source. Il semble que la réponse à ma question soit juste non alors :)
Vous pouvez élever un bug avec Git Core?
Est-il possible de demander à utiliser Git CRLF au lieu de simplement LF à la fin des lignes qu'il met dans un fichier quand il a besoin de la fusion?
... est en fait possible, git 2.7.2+ (Février 2016) .
Et vous n'avez rien à faire.Voir engager 15980de , commit 86efa21 (27 janvier 2016) par Johannes Schindelin (
dscho ).
(issu de la fusion par Junio Hamano C -gitster -commit ab2c107 17 Fév 2016)
fusion-file : laisser les marqueurs de conflit de style fin correspondent de ligne du contexteLors de la fusion des fichiers avec des fins de ligne CR / LF, les marqueurs de conflit devraient correspondent à ceux, de peur que le fichier de sortie les fins de lignes mixtes .
Ceci est particulièrement intéressant sur Windows, où certains éditeurs obtiennent vraiment confus par les fins de ligne mixtes.
La version originale de ce patch par Beat Bolli respecté
core.eol , et une amélioration ultérieure de ce développeur aussi respectégitattributes .
Cette approche a été sous-optimale, bien que:fusion-fichier git a été inventé comme drop-in de remplacement pour la fusion GNU et en tant que telle n'a pas de problème d'exploitation en dehors de tout référentiel!Un autre problème avec l'approche originale a été souligné par Junio Hamano: les dépôts anciens peuvent avoir leurs fichiers texte en utilisant commis les fins de ligne CR / LF (et
core.eol etgitattributes nous donnerait un fausse impression là-bas). , l'approche beaucoup supérieure est donc de il suffit de sélectionner les fins de ligne du contexte, le cas échéant .Nous ne fait pas de regarder le ensemble contexte du tout:
- si les fichiers sont tous LF uniquement, ou si elles ont toutes les fins de ligne CR / LF, il suffit de regarder juste un à ligne pour correspondre à ce style.
- Et si les fins de ligne sont de toute façon mixte, il est toujours ok Imiter juste eol ce une seule ligne: nous allons simplement ajouter à la pile de fins de ligne mixte, et il n'y a rien que nous pouvons faire à ce sujet.
Alors ce que nous faisons est: nous regardons la ligne précédant le conflit, la chute retour à la ligne précédente que dans le cas où il était la dernière ligne et n'a pas eu ligne se terminant en retombant à la première ligne, d'abord dans le premier post-image, puis le second post-image et enfin la pré-image.
Si nous trouvons CR / LF cohérente (ou indécis) le style de fin de ligne, nous faisons correspondre qui, sinon nous utilisons les fins de ligne LF uniquement pour les marqueurs de conflit.Notez que si il est vrai qu'il doit y avoir au moins deux lignes nous peut regarder (sinon il n'y aurait pas de conflit), le même n'est pas vrai pour la ligne Répétitions : les trois dossiers en question pourrait consister en un tout seule ligne sans fin de ligne, chacune d'elles. Dans ce cas, nous retombons à LF en utilisant uniquement.
Vous nous avez dit précisément zéro information sur votre environnement. Quel système d'exploitation? Si c'est Windows, quelle distribution GIT utilisez-vous? Est-ce git pour Windows ou Cygwin Git ou un seul produit tiers intégrant GIT? Quelle version? Quels paramètres Git liés à EOL sont en vigueur?
Je ne pense pas que beaucoup de cela est pertinent. Tout ce que j'ai demandé a été " Pour l'enregistrement, j'utilise Cygwin Git sous Windows. Actuellement, j'ai un autocrôle défini sur FALSE.
Vous sous-estimez les complications GIT doit traiter de traiter les problèmes d'EOL. Un coup d'œil rapide sur la page
git-config manuel ou la recherche afin que "git + cr + lf" vous dirait. Et ensuite, il y a une inadéquation d'impédance entre les plates-formes logicielles (par exemple, Git pour Windows implémente de nombreuses bizarreries pour faire fonctionner la chose sur Windows) qui peut affecter la manière dont Git fonctionne.Démarrer Git 2.8+ (mars 2016), ce problème ne se reproduira plus. Voir Ma réponse ci-dessous