Erreur Git "fatal : ambiguous argument 'HEAD' : unknown revision or path not in the working tree"

Question

J'essaie d'initialiser un nouveau dépôt Git à partir de Debian (en fait une VM sur VirtualBox, installée et fonctionnant sur Mac OS X) :

cd ~
mkdir test
cd test
git init

Initialized empty Git repository in /home/david/test/.git/
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

[david@server-VM-001:test  (master #) $]

Quel est le problème ?

Answer 1

Comme d'autres l'ont souligné, ce message provient de l'invite de votre shell. Le problème est que dans un référentiel fraîchement créé HEAD ( .git/HEAD ) pointe vers une référence qui n'existe pas encore.

% git init test
Initialized empty shared Git repository in /Users/jhelwig/tmp/test/.git/
% cd test
% cat .git/HEAD
ref: refs/heads/master
% ls -l .git/refs/heads
total 0
% git rev-parse HEAD
HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

On dirait que rev-parse est utilisé sans qu'un contrôle d'erreur suffisant n'ait été effectué au préalable. Après la création du premier commit .git/refs/heads est un peu différent et git rev-parse HEAD n'échouera plus.

% ls -l .git/refs/heads
total 4
-rw------- 1 jhelwig staff 41 Oct 14 16:07 master
% git rev-parse HEAD
af0f70f8962f8b88eef679a1854991cb0f337f89

Dans la fonction qui met à jour les informations Git pour le reste de mon invite de commande (version fortement modifiée du thème d'invite wunjo pour ZSH), j'ai ce qui suit pour contourner le problème :

zgit_info_update() {
    zgit_info=()

    local gitdir=$(git rev-parse --git-dir 2>/dev/null)
    if [ $? -ne 0 ] || [ -z "$gitdir" ]; then
        return
    fi

    # More code ...
}

Answer 2

J'utilise habituellement Git sur ma machine Linux, mais au travail je dois utiliser Windows. J'ai eu le même problème en essayant de faire le premier commit dans un environnement Windows.

Pour ceux qui rencontrent encore ce problème, j'ai pu le résoudre comme suit :

git commit --allow-empty -n -m "Initial commit."

Answer 3

J'ai eu ce problème lorsque j'ai eu un affichage personnalisé dans mon terminal lors de la création d'un nouveau projet Git (j'ai affiché ma branche avant le nom du chemin, par exemple, <branch>:/current/path).

Il m'a suffi de faire mon premier commit sur ma branche master pour que ce message disparaisse.

Answer 4

Dans mon cas, il s'agissait de la profondeur du clone (que j'ai réglé sur 1 et l'a oubliée)

Jenkins était en cours :

git rev-parse 2865c1ce8248de835b5a3fbfcce09e7346d5e3ea^{commit}

(Ce commit est quelques commits derrière HEAD).

Lorsque l'on clone/récupère avec --depth=1 J'obtiendrais alors l'erreur suivante lors de l'exécution de git rev-parse . Lors du clonage avec un nombre plus élevé (ou sans --depth ), git rev-parse a bien fonctionné.

Cela peut être légèrement différent de la commande de l'OP, mais cela peut aider quelqu'un.

Answer 5

Jacob Helwig mentions dans sa réponse que :

Il semble que rev-parse soit utilisé sans vérification d'erreur suffisante au préalable

Engagement 62f162f de Jeff King ( peff ) devrait améliorer la robustesse des git rev-parse dans Git 1.9/2.0 (Q1 2014) (en plus de commit 1418567 ) :

Dans les cas où il n'y a pas de correspondance (par exemple, " doesnotexist..HEAD "), nous devrions alors essayer de traiter l'argument comme un nom de fichier.
try_difference() a raison de le faire, et ne paie jamais dans ce cas.
Cependant, try_parent_shorthand() ne se désolidarise jamais, ce qui entraîne des messages d'erreur incorrects, voire des résultats erronés :

$ git rev-parse foobar^@
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'