Pourquoi le nom d'une branche ne peut-il pas contenir le caractère "espace" ?

Question

J'ai essayé :

git branch "MyProj/bin/ ignored"

et reçu :

fatal: 'MyProj/bin/ ignored' is not a valid branch name.

El git-branch pointe vers la page de manuel git-check-ref-format pour obtenir les règles actuelles pour un nom de branche valide.

Bien sûr, la raison de l'erreur fatale ci-dessus semble être l'inclusion d'un caractère d'espace.

Une idée de la raison pour laquelle, à notre époque, les espaces sont toujours exclus du nom d'une branche (je m'y serais attendu dans l'ancien CVS, par exemple, mais dans Git ?)

Quelles pourraient être les raisons techniques valables pour cela ?

Answer 1

Je ne sais pas si vous allez trouver une raison purement technique au fond de cette affaire. Cependant, je peux vous dire que les espaces ont tendance à perturber toutes sortes d'utilitaires *nix et le traitement des noms de fichiers, et que c'est peut-être pour éviter de faire accidentellement quelque chose de mal plus tard. Après tout, une branche git se résume à un fichier dans le repo et cela évite de traiter les espaces dans le nom de ce fichier (spécifiquement, une branche est un fichier dans .git/refs/heads/, comme mentionné dans le commentaire).

Je pense que la raison est surtout philosophique et qu'elle vise à simplifier les choses. Les noms de branches sont des noms lisibles par l'homme qui n'ont aucune raison d'être compliqués (et qui nécessitent de taper deux caractères supplémentaires à chaque fois haha, pour invoquer le fantôme de l'administrateur système qui a aliasé chaque commande avec une combinaison indéchiffrable de trois lettres). Autrement connu comme l'argument "pourquoi cd n'est pas chdir".

Answer 2

Vieux fil, mais bon..
sur un mac, j'utilise alt + espace. cela ajoutera un caractère invisible qui fera l'affaire pour vous. attention : ce n'est pas un 'espace', c'est un caractère invisible. visuellement, c'est la même chose, mais effectivement, ce n'est pas la même chose. Il est probable qu'à 100%, cela va perturber tous les autres et apporter le chaos partout, mais bon, pour le plaisir pourquoi pas ? xD

git checkout -b US24024 Automated Tests - Profile A
Switched to a new branch 'US24024 Automated Tests - Profile A'

Answer 3

Il existe une solution de contournement possible si vous êtes suffisamment désespéré. Il y a beaucoup de caractères ressemblant à des espaces dans le jeu Unicode. Mais seul U+0020 est l'espace qui n'est pas autorisé. Prenez par exemple une espace insécable et vous pouvez avoir un nom de branche avec des espaces. Le problème principal est que votre clavier n'a probablement pas de touche pour ce point de code. J'utilise le script suivant pour contourner ce problème :

#!/bin/zsh
git co -b "${@// / }"

Il remplace simplement tous les espaces dans les arguments par des espaces insécables...

Answer 4

Parce qu'utiliser correctement les noms de chemin dans les scripts du shell est difficile. A partir du lien git check-ref-format la page de manuel elle-même :

Ces règles facilitent l'analyse des noms de référence par les outils basés sur le shell script. de référence, l'expansion du nom de chemin par le shell lorsqu'un nom de référence est utilisé non cité (par erreur), et évitent également les ambiguïtés dans certaines expressions de noms de référence (voir gitrevisions(7)) :

Voir aussi Noms de fichier et de chemin d'accès en Shell : comment le faire correctement :

Le problème fondamental est qu'aujourd'hui la plupart des Unix-likes permettent aux noms de fichiers d'inclure presque tous les octets . Cela inclut les nouvelles lignes, les tabulations, le caractère d'échappement (y compris les séquences d'échappement qui peuvent exécuter des commandes lorsqu'elles sont affichées), d'autres de contrôle, les espaces (partout !), les tirets de tête (-), les métacaractères et les séquences d'octets qui ne sont pas des chaînes UTF-8 légales.

...

Cependant, cette faille dans les noyaux de type Unix (permettant des noms de fichiers dangereux) se combine avec des faiblesses supplémentaires dans le langage shell Bourne, ce qui le rend encore plus difficile pour l'interpréteur de commandes de gérer correctement les noms de fichier et les noms de chemin. I pense que le shell est un langage raisonnable pour de courts scripts, lorsqu'il est correctement utilisé, mais la permissivité excessive des noms de fichiers transforme les tâches faciles en tâches faciles en tâches facilement erronées.

Answer 5

Ce n'est pas autorisé car cela compliquerait la fonctionnalité de la commande "git checkout".

Ex : Considérons que vous avez actuellement une branche appelée , bien que vous soyez actuellement dans le master. Si vous exécutez la commande

(master) : git checkout -b mon correctif

git ne saurait pas si vous voulez créer une nouvelle branche appelée "my fix" ou si vous voulez créer une nouvelle branche appelée "my" qui est liée à votre "fix" original, plutôt qu'à la branche "master".

Fuente: https://git-scm.com/docs/git-checkout (Documentation Git)