Czy Git ostrzega mnie, jeśli skrócony identyfikator zatwierdzenia może odnosić się do 2 różnych zatwierdzeń?

Jeśli cee157może odnosić się do 2 różnych identyfikatorów zatwierdzeń, takich jak

cee157eb799af829a9a0c42c0915f55cd29818d4 i cee1577fecf6fc5369a80bd6e926ac5f864a754b

czy Git ostrzeże mnie, jeśli wpiszę git log cee157? (lub Git 1.8.5.2 (Apple Git-48) pozwala mi wpisać git log cee1).

Myślę, że powinno, chociaż nie mogę znaleźć żadnego wiarygodnego źródła, które mówi, że tak.

Powinien dać ci coś takiego:

$ 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>...]'

Właśnie przetestowałem to na prawdziwym repozytorium Git, znajdując zatwierdzenia ze zduplikowanymi przedrostkami, takimi jak ten:

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

Spowoduje to pobranie listy wersji master, wycięcie pierwszych 4 znaków i wyrzucenie pozostałych, policzenie duplikatów i posortowanie numeryczne. W moim stosunkowo małym repozytorium ~ 1500 zatwierdzeń znalazłem sporo wersji ze wspólnym 4-cyfrowym prefiksem. Wybrałem 4-cyfrowy prefiks, ponieważ wydaje się, że jest to najkrótsza dozwolona długość obsługiwana przez Git. (Nie działa z 3 cyframi lub mniej, nawet jeśli nie jest niejednoznaczne.)

Btw to nie była literówka, nie wiem, dlaczego komunikat o błędzie o niejednoznacznym SHA1 pojawia się dwukrotnie, niezależnie od liczby duplikatów SHA1 (próbowano z 2 i 3):

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

(Obie włączone stderr. Właściwie całe wyjście jest włączone stderr, nic nie jest włączone stdout.)

Przetestowano w systemie Windows:

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

Myślę, że to na pewno powiedzieć, że jeśli wersja jest> = 1.8.1, Git będzie ostrzegać duplikatów. (Odmówi działania z duplikatami.) Myślę, że dużo starsze wersje też działały w ten sposób.

AKTUALIZACJA

Podczas testowania potrzebujesz co najmniej 4-cyfrowego SHA1 ze względu int minimum_abbrev = 4na środowisko . C. (Dzięki @devnull za wskazanie tego!)

Oryginalny plakat stwierdza:

Myślę, że powinno, chociaż nie mogę znaleźć żadnego wiarygodnego źródła, które mówi, że tak.

Autorytatywne źródło można znaleźć w kodzie źródłowym get_short_sha1() .

Cytując to :

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

a to :

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;

Ponadto istnieją testy zapewniające, że funkcja działa zgodnie z oczekiwaniami.