Git m'avertit-il si un ID de commit abrégé peut faire référence à 2 commits différents?

130

If cee157peut faire référence à 2 ID de validation différents, tels que

cee157eb799af829a9a0c42c0915f55cd29818d4 et cee1577fecf6fc5369a80bd6e926ac5f864a754b

Git me préviendra-t-il si je tape 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 dit que ce serait le cas.

git

— non-polarité
source

Voir man gitrevisions, ce qui implique au moins qu'un avertissement sera donné car il indique que vous pouvez nommer une révision avec son nom SHA1-1 complet ou "une sous-chaîne principale qui est unique dans le référentiel".

— chepner

avez-vous 17 commits différents? essayez juste git log c... et voyez.

— djechlin

Dans ELL, je marquerais probablement ceci comme [référence générale]

— juste la moitié

@djechlin J'ai besoin d'au moins 4 chiffres. git log abcdit fatal: ambiguous argument 'abc': unknown revision or path not in the working tree.même si j'ai un SHA1 unique commençant par abc. Ne fonctionne pas avec 1-2-3 chiffres, 4 semble être le minimum. Testé sous Windows (1.8.1) et Mac (1.9.1).

— janos

@janos C'est parce que environment.h définit minimum_abbrevune valeur de 4.

— devnull

Réponses:

168

Cela 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 <command> [<revision>...] -- [<file>...]'

Je viens de tester cela sur un vrai dépôt Git, en trouvant des commits avec des préfixes en double comme celui-ci:

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

Cela prend la liste des révisions dans master , supprime les 4 premiers caractères et jette le reste, compte les doublons et trie numériquement. Dans un mon référentiel relativement petit d'environ 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 légale 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 concernant SHA1 ambigu apparaît deux fois, quel que soit le nombre de SHA1 en double (essayé avec 2 et 3):

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

(Les deux sont stderractivés. En fait, toute la sortie est activée stderr, rien n'est activé stdout.)

Testé sous Windows:

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

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

METTRE À JOUR

Lors du test, vous avez besoin d'un minimum de SHA1 à 4 chiffres, à cause de int minimum_abbrev = 4dans environment.c . (Merci @devnull pour l'avoir signalé!)

— Janos
source

L'erreur apparaît-elle deux fois même s'il y a plus de deux commits avec des préfixes correspondants?

— Nit

@Nit oui, même s'il y a 3 dups, le message apparaît deux fois. J'ai mis à jour ma réponse pour clarifier cela.

— janos

Compte tenu de la structure du code source git, il semble que l'une des deux sorties est un avertissement et l'autre une erreur. Pas certain, cependant.

— Izkata

@MarkHurd à la fois sur stderr. En fait, toute la sortie est sur stderr, rien sur stdout. (ce qui a du sens)

— janos

L'affiche originale déclare:

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

La source faisant autorité se trouve 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.

— devnull
source