2017-10-18 5 views

Répondre

0

É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 --prefixl'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.

+0

Oui, je voulais dire 'git rev-parse --short HEAD' au lieu de' git rev-parse --short'. J'ai mis à jour la question. – cowlinator