Hi Linus, On Thu, Dec 5, 2024 at 8:19 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 5 Dec 2024 at 10:16, Geert Uytterhoeven <geert+renesas@xxxxxxxxx> wrote: > > Hence according to the Birthday Paradox, collisions of 12-chararacter > > git commit IDs are imminent, or already happening. > > Note that ambiguous commit IDs are not even remotely as scary as this implies. > > Yes, the current kernel tree has over ten million objects, and when > you look at stable trees etc, you can easily see more. > > But commits are only a fraction (about 1/8th) of the total objects. My > tree is at about 1.3M commits, so we're basically an order of > magnitude off the point where collisions start being an issue wrt > commit IDs. > > Can you find collisions by looking at all objects? Yes. Git will do > that for you, and tell you their types. But to take one recent > example, let's do the 6.12 commit: > adc218676eef25575469234709c2d87185ca223a. To get an ambiguous ID, you > have to go down to 6 characters, and even then git will tell you > there's only one object that is a commit, ie > > $ git show adc218 > > results in > > error: short object ID adc218 is ambiguous > hint: The candidates are: > hint: adc218676eef commit 2024-11-17 - Linux 6.12 > hint: adc2184009c5 blob > > so right now you have a collision in six digits for that commit, but > even then it's actually still entirely unambiguous once you know > you're talking about a commit. That's true for the basic command line tools... > Make the tools deal with the cases we already have, and you'll find > that the shortening is a complete non-issue. FTR, cgit can use some improvements, as https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adc218 just tells you "Bad object id: adc218". Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
