Cet article oublie un peu l'existence des alias qui nous affranchit un peu de tout ça.
Moi je me dis juste que tout dépend si il est possible de décrire l'intérêt de la commande en moins d'une quinzaine de lettres. Par exemple kubectl c'est un peu long mais c'est pas grave en interactif tous les admins kubernetes vont utiliser un alias k.
Dans le cas de git, c'est un distributed version control system. C'est trop long à dire, dvcs n'est pas mega parlant. Du coup git ça va, d'autant plus qu'on peut lui configurer des alias pour les sous-commandes. Mais en même temps ça me dérange un peu parce que ce n'est pas une commande historique ni posix et qu'au final il aurait très bien pu être plus long que ça n'aurait pas dérangé et beaucoup de monde vont privilégier des alias shell plutôt que des alias git:
des exemples
gp au lieu de git p qui aurait été un alias pour git pull
gco au lieu de git co qui aurait été un alias pour git checkout
gst au lieu de git s ou git st qui aurait été un alias pour git status
ga pour git add
gcm au lieu de git cm qui aurait été un alias pour git commit -m
glo au lieu de git lo qui aurait été n alias pour git log --oneline
Au final un nom long et expressif est toujours utile pour la compréhension des scripts, d'autant plus qu'on va quasi toujours le passer sous forme de fonction ou variable.
[^] # Re: Emplacements des lettres
Posté par Psychofox (Mastodon) . En réponse au lien The Poetics of CLI Command Names. Évalué à 2.
Cet article oublie un peu l'existence des alias qui nous affranchit un peu de tout ça.
Moi je me dis juste que tout dépend si il est possible de décrire l'intérêt de la commande en moins d'une quinzaine de lettres. Par exemple kubectl c'est un peu long mais c'est pas grave en interactif tous les admins kubernetes vont utiliser un alias k.
Dans le cas de git, c'est un distributed version control system. C'est trop long à dire, dvcs n'est pas mega parlant. Du coup git ça va, d'autant plus qu'on peut lui configurer des alias pour les sous-commandes. Mais en même temps ça me dérange un peu parce que ce n'est pas une commande historique ni posix et qu'au final il aurait très bien pu être plus long que ça n'aurait pas dérangé et beaucoup de monde vont privilégier des alias shell plutôt que des alias git:
des exemples
gp au lieu de git p qui aurait été un alias pour git pull
gco au lieu de git co qui aurait été un alias pour git checkout
gst au lieu de git s ou git st qui aurait été un alias pour git status
ga pour git add
gcm au lieu de git cm qui aurait été un alias pour git commit -m
glo au lieu de git lo qui aurait été n alias pour git log --oneline
Au final un nom long et expressif est toujours utile pour la compréhension des scripts, d'autant plus qu'on va quasi toujours le passer sous forme de fonction ou variable.