Est-ce que Git me prévient si un identifiant de validation abrégé peut faire référence à deux commits différents?

Si cee157 peut faire référence à 2 identifiants de validation différents, tels que

cee157eb799af829a9a0c42c0915f55cd29818d4 et cee1577fecf6fc5369a80bd6e926ac5f864a754b

Git me préviendra-t-il si je tape dans git log cee157 ? (ou Git 1.8.5.2 (Apple Git-48) me permet de taper git log cee1 ).

Je pense que ce devrait être le cas, même si je ne trouve aucune source faisant autorité qui le ferait.

Il devrait vous donner quelque chose comme ceci:

 $ git log cee157 error: short SHA1 cee157 is ambiguous. error: short SHA1 cee157 is ambiguous. fatal: ambiguous argument 'cee157': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git  [...] -- [...]' 

Je viens de tester ceci sur un vrai repository Git, en trouvant des commits avec des préfixes en double comme ceci:

 git rev-list master | cut -c-4 | sort | uniq -c | sort -nr | head 

Cela prend la liste des révisions dans master , découpe les 4 premiers caractères et jette le rest, compte les doublons et les sortinge numériquement. Dans un référentiel relativement petit de ~ 1500 commits, j’ai trouvé pas mal de révisions avec un préfixe commun à 4 chiffres. J’ai choisi un préfixe à 4 chiffres car cela semble être la longueur juridique la plus courte prise en charge par Git. (Ne fonctionne pas avec 3 chiffres ou moins, même s’il n’est pas ambigu.)

Btw ce n’était pas une faute de frappe, je ne sais pas pourquoi le message d’erreur sur SHA1 ambigu apparaît deux fois, indépendamment du nombre de SHA1 en double (essayé avec 2 et 3):

 error: short SHA1 cee157 is ambiguous. error: short SHA1 cee157 is ambiguous. 

(Les deux sur stderr . En fait, la sortie entière est sur stderr , rien sur stdout .)

Testé sous Windows:

 $ git --version git version 1.8.1.msysgit.1 

Je pense qu’il est prudent de dire que si votre version est> = 1.8.1, Git vous avertira des doublons. (Il refusera de fonctionner avec des doublons.) Je suppose que beaucoup de versions plus anciennes fonctionnaient de cette façon également.

METTRE À JOUR

Lorsque vous testez cela, vous avez besoin d’un minimum de 4 chiffres SHA1, car int minimum_abbrev = 4 dans environment.c . (Merci @devnull de l’ avoir signalé!)

L’affiche originale indique:

Je pense que ce devrait être le cas, même si je ne trouve aucune source faisant autorité qui le ferait.

La source faisant autorité peut être trouvée dans le code source, get_short_sha1() .

Citant ceci :

 if (!quietly && (status == SHORT_NAME_AMBIGUOUS)) return error("short SHA1 %.*s is ambiguous.", len, hex_pfx); 

et ceci :

 if (!ds->candidate_checked) /* * If this is the only candidate, there is no point * calling the disambiguation hint callback. * * On the other hand, if the current candidate * replaced an earlier candidate that did _not_ pass * the disambiguation hint callback, then we do have * more than one objects that match the short name * given, so we should make sure this one matches; * otherwise, if we discovered this one and the one * that we previously discarded in the reverse order, * we would end up showing different results in the * same repository! */ ds->candidate_ok = (!ds->disambiguate_fn_used || ds->fn(ds->candidate, ds->cb_data)); if (!ds->candidate_ok) return SHORT_NAME_AMBIGUOUS; 

De plus, des tests existent également pour s’assurer que la fonctionnalité fonctionne comme prévu.