Édition (par question éditée): puisque HEAD
spécifie toujours la révision en cours et ne dépend pas d'un chemin dans l'arbre de travail, --prefix
n'a aucun effet ici.
[réponse originale (qui comprend ce qui précède) ci-dessous.]
Il est pas vraiment clair pour moi ce que vous avez l'intention de demander ici.
En interne, git rev-parse
localise l'arborescence de travail actuelle et d'autres éléments. Si elle est exécutée sans arguments supplémentaires, elle ne sert à rien. Par exemple:
$ git rev-parse --short
fatal: Needed a single revision
Cette commande particulière git rev-parse
échoue simplement. Il le fera indépendamment de --prefix
ou de son absence.
(S'il n'y a pas de dépôt Git il échoue encore plus tôt:
fatal: Not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
mais ce n'est pas très intéressant.)
L'option --short
raccourcit simplement l'ID de hachage présenté sur le succès.
L'ID de hachage produit en analysant un spécificateur de révision peut dépend de l'arbre de travail, mais pas toujours. Par exemple:
git rev-parse HEAD
produit le courant (ou HEAD
ou @
) commettras hachage. L'utilisation de --prefix
ne l'affectera pas. Mais:
git rev-parse HEAD:./path
produit le hachage d'arbre ou blob pour la donnée path
l'argument relatif à la position actuelle dans le référentiel; ici, en utilisant --prefix
l'affectera.
Pendant ce temps, git rev-parse
peut être utilisé pour faire autre chose que produire des hachages de validation. Ici, les deux --short
et --prefix
peuvent devenir totalement non pertinents. Par exemple:
$ git rev-parse --sq-quote --short --prefix x HEAD:./Documentation
'--short' '--prefix' 'x' 'HEAD:./Documentation'
alors cela importe vraiment quels sont les autres paramètres et options que vous fournissez.
Oui, je voulais dire 'git rev-parse --short HEAD' au lieu de' git rev-parse --short'. J'ai mis à jour la question. – cowlinator