Catatan: Anda dapat meminta git rev-parse --short
SHA1 yang terpendek namun unik.
Lihat " git dapatkan hash pendek dari hash biasa "
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
Seperti yang Anda lihat dalam contoh saya SHA1 memiliki panjang 5 bahkan jika saya menentukan panjang 4.
Untuk repo besar, 7 tidak cukup sejak 2010, dan melakukan dce9648 oleh Linus Torvalds sendiri (git 1.7.4.4, Okt 2010):
Default 7 berasal dari cukup awal dalam pengembangan git, ketika tujuh digit hex banyak (mencakup sekitar 250+ juta nilai hash).
Saat itu saya berpikir bahwa revisi 65 ribu adalah banyak (itu yang akan kita bahas di BK), dan setiap revisi cenderung sekitar 5-10 objek baru, jadi sejuta objek adalah jumlah yang besar.
(BK = BitKeeper)
Hari-hari ini, kernel bahkan bukan proyek git terbesar, dan bahkan kernel memiliki sekitar 220 ribu revisi ( jauh lebih besar dari pohon BK sebelumnya) dan kami mendekati dua juta objek.
Pada titik itu, tujuh digit hex masih unik untuk banyak dari mereka, tetapi ketika kita berbicara tentang hanya dua urutan perbedaan besarnya antara jumlah objek dan ukuran hash, akan ada tabrakan dalam nilai hash terpotong.
Itu bahkan tidak lagi mendekati tidak realistis - itu terjadi setiap saat.
Kita berdua harus meningkatkan singkatan default yang tidak realistis kecil, dan menambahkan cara bagi orang untuk menetapkan standar per proyek mereka sendiri dalam file konfigurasi git .
core.abbrev
Atur panjang nama objek yang disingkat.
Jika tidak ditentukan, banyak perintah disingkat menjadi 7 hexdigits, yang mungkin tidak cukup untuk nama objek yang disingkat agar tetap unik untuk waktu yang cukup lama.
environment.c
:
int minimum_abbrev = 4, default_abbrev = 7;
Catatan: Seperti yang dikomentari di bawah ini oleh marco.m , core.abbrevLength
diganti namanya di core.abbrev
Git 1.7.4.4 yang sama di commit a71f09f
Ganti nama core.abbrevlength
kembali menjadicore.abbrev
Itu sesuai dengan --abbrev=$n
opsi baris perintah setelah semua.
Baru-baru ini, Linus ditambahkan dalam melakukan e6c587c (untuk Git 2.11, Q4 2016):
(seperti yang disebutkan di Matthieu Moy 's jawaban )
Pada hari-hari yang cukup awal, kami entah bagaimana memutuskan untuk menyingkat nama objek menjadi 7-hexdigits, tetapi seiring bertambahnya proyek, semakin besar kemungkinan nama objek pendek dibuat pada hari-hari sebelumnya dan dicatat dalam pesan log tidak lagi unik.
Saat ini proyek kernel Linux membutuhkan 11 hingga 12 hexdigits, sementara Git sendiri membutuhkan 10 hexdigits untuk secara unik mengidentifikasi objek yang mereka miliki, sementara banyak proyek yang lebih kecil mungkin masih baik-baik saja dengan default 7-hexdigit asli. Satu ukuran tidak cocok untuk semua proyek.
Memperkenalkan suatu mekanisme, di mana kami memperkirakan jumlah objek dalam repositori atas permintaan pertama untuk menyingkat nama objek dengan pengaturan default dan muncul dengan standar waras untuk repositori. Berdasarkan harapan bahwa kita akan melihat tabrakan dalam repositori dengan 2^(2N)
objek ketika menggunakan nama objek yang disingkat menjadi N bit pertama, gunakan jumlah hexdigit yang cukup untuk menutupi jumlah objek dalam repositori.
Setiap hexdigit (4-bit) yang kita tambahkan ke nama yang disingkat memungkinkan kita untuk memiliki empat kali (2-bit) karena banyak objek dalam repositori.
Lihat komit e6c587c (01 Okt 2016) oleh Linus Torvalds ( torvalds
) .
Lihat komit 7b5b772 , komit 65acfea (01 Okt 2016) oleh Junio C Hamano ( gitster
) .
(Digabung oleh Junio C Hamano - gitster
- dalam komit bb188d0 , 03 Okt 2016)
Properti baru itu (menebak default yang masuk akal untuk nilai singkatan SHA1) memiliki efek langsung pada bagaimana Git menghitung nomor versinya sendiri untuk rilis .