En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 5.
En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.