7 votes

Une façon correcte et rapide de tester le répertoire git et la branche git ?

En essayant de mettre en place mon nouveau poisson Shell rapidement, j'ai fini par tester des façons d'obtenir le nom de la branche et aussi de tester si j'étais sur un dépôt git. J'ai trouvé (1) git rev-parse --abbrev-ref HEAD , (2) git symbolic-ref HEAD | sed 's/refs\/heads\///' y (3) git describe --contains --all HEAD font très bien l'affaire.

Je suis curieux parce que j'aime la simplicité de (1) mais sur un site neuf et intact (tout juste git init ed), il me donne une erreur "fatal :", alors que (2) fonctionne comme prévu, c'est-à-dire qu'il me donne une valeur par défaut. maître comme sortie. Le problème est que, même avec une erreur "fatal :", le code de retour est 0. Est-ce le comportement souhaité ?

Pour tester si je me trouvais dans un dépôt git, j'ai fini par simplement tester si le répertoire courant avait un dossier ".git" : test -d ".git" . Solution rudimentaire, mais qui fonctionne, et qui semble plus rapide que l'utilisation de n'importe quelle commande git.

Donc, mes questions sont :

  1. Ne devrait-il pas y avoir ce "fatal :" avec (1) renvoie un code de sortie différent de 0 ? Si c'est effectivement un bogue, puisque je ne sais pas comment les gens de git ont standardisé leurs codes de retour, où dois-je le signaler ?
  2. Je sais que si je redirige (1) avec ^ /dev/null (pour ceux qui ne le savent pas, ^ est la même chose que 2> ), je n'obtiendrai pas l'erreur, mais le message suivant apparaîtra HEAD au lieu de maître, mais si je cat .git/HEAD j'obtiens : ref: refs/heads/master . Que devrait-il vraiment dire ? Avec master Je suis juste ignorant et pointilleux, parce que ça devrait plutôt dire HEAD ? Je veux dire dans le cas d'un juste git init dépôt d'archives.
  3. Avez-vous réellement évalué toutes les solutions possibles au cours de votre quête d'une bonne invite ?

Voici le code que j'utilise pour faire du benchmarking (pour les poissons) :

set -l before (date +%s%N)
git rev-parse --abbrev-ref HEAD
set -l after (date +%s%N)
set -l elapsed_time (expr $after - $before)
echo $elapsed_time

Merci d'avance !

PS : Les outils sont les dernières versions GNU, je veux dire, sed , date y expr . Je suis désolé s'il y a trop d'informations ou si quelque chose n'a pas de sens. Soyez indulgent avec moi. Merci.

EDITAR: Comme quelqu'un l'a correctement deviné dans une réponse, l'erreur entière est :

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

4voto

Christopher Points 744

Cela ne répond pas entièrement à vos questions mais c'est probablement un peu plus qu'un simple commentaire :

  1. D'après d'autres commentaires dans votre réponse, je pense que l'erreur que vous avez vue est fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Cela se produit parce que vous effectuez ces tests sur un tout nouveau dépôt git, un dépôt qui n'a pas de travail engagé. Non seulement ce n'est pas vraiment un test équitable (vos performances seront par définition plus mauvaises sur un dépôt plus important), mais c'est aussi un cas limite dans presque tous les domaines. Par exemple, .git/HEAD montre ref: refs/heads/master par convention. L'erreur est déclenchée parce que HEAD est ambiguë. Vous n'avez pas d'historique, donc toute valeur passée à rev-parse seraient traités de la même manière. De plus, ça ne sort pas de 0 pour moi :

    $ git init /tmp/test && cd /tmp/test
    $ git rev-parse --abbrev-ref HEAD
    $ echo $?
    128

    En résumé, ne vous inquiétez pas de cette erreur. Procurez-vous l'un des énormes dépôts Android, ou peut-être le noyau linux, et testez votre prompt là-bas.

  2. HEAD n'est pas une branche. C'est un pointeur vers l'état check-out. Quand vous avez une branche extraite, c'est une référence symbolique à cette branche. Lorsque vous êtes dans l'état 'detached HEAD', la balise HEAD Le pointeur pointe vers un commit. On obtient HEAD comme le rendement en utilisant la méthode (1) car rev-parse ne fait que répercuter la valeur de la refspec passée dans l'erreur. Essayez-le avec blah ; vous verrez la même chose.

  3. Je n'ai pas vraiment évalué les solutions, mais il y a quelques choses que vous pourriez essayer (les deux sont utilisés dans mon invite zsh, que je n'ai pas écrit, et les deux se sont bien comportés) :

    git rev-parse --is-inside-work-tree ;# avoids your 'test -d .git' call
    ref=$(git symbolic-ref HEAD 2> /dev/null) ;# grab the full refspec
    branch=$(echo ${ref#refs/heads/}) ;# extract the branch name

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X