git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [REVISED PATCH 2/6] Introduce commit notes

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Jul 19, 2007, 17:50 UTC
Message-ID
<alpine.LFD.0.999.0707191043430.27353@woody.linux-foundation.org>
In-Reply-To
<20070719103436.GA9143@dspnet.fr.eu.org>
On Thu, 19 Jul 2007, Olivier Galibert wrote:
Show 10 quoted lines
> On Wed, Jul 18, 2007 at 08:28:27PM -0700, Linus Torvalds wrote:
> > And yes, the "search for zero bytes" is not *guaranteed* to find any 
> > beginning at all, if you have lots of short names, *and* lots of zero 
> > bytes in the SHA1's. But while short names may be common, zero bytes in 
> > SHA1's are not so much (since you should expect to see a very even 
> > distribution of bytes, and as such most SHA1's by far should have no zero 
> > bytes at all!)
> 
> The probability of a sha1 to have a zero is approximatively 0.075.
> That's 1 in 13, more or less.
Sure. And since we handle it fine even when it does happen, we don't care.

In fact, since we only need 20 non-zero bytes in between zeroes to know that it's ok, and since the ASCII part is already 7 bytes of "mode + space" plus <n> bytes of actual name (let's say that names average to be about 8 characters - which is low: in the kernel it seems to be about 10.5 characters), we can say that the ASCII part of a tree tends to be about 15 characters.

So in order to be unlucky, it's not enough for the previous SHA1 to have a NUL character in it, it actually has to be in the last five bytes of the SHA1 - so now we're talking something like a 1:50 chance.

And with longer names, it matters even less (to the point where it matters not at all if all filenames are >= 14 characters in length).

So we can be unlucky, but it's fairly rare, and when it happens, at worst we'll just need to scan to the next entry (and if we're *really* unlucky and it keeps happening until we scan until the end, we'll have to do the linear search).

The point being that you always get the right answer, and the likelihood that you have to do something slow to get that rigth answer is really really low.

		Linus
Previous: Olivier GalibertNext: Wincent Colaiuta
Message 22 of 42 in “Introduce commit notes”
  1. 0/6 Introduce commit notesJohannes Schindelin, Jul 15, 2007
  2. 1/6 Rename git_one_line() to git_line_length() and export itJohannes Schindelin, Jul 15, 2007
  3. 2/6 Introduce commit notesJohannes Schindelin, Jul 15, 2007
  4. Junio C HamanoJul 15, 2007
  5. Johannes SchindelinJul 15, 2007
  6. Junio C HamanoJul 16, 2007
  7. Junio C HamanoJul 16, 2007
  8. 2/6 Introduce commit notesJohannes Schindelin, Jul 19, 2007
  9. Linus TorvaldsJul 19, 2007
  10. Junio C HamanoJul 19, 2007
  11. Junio C HamanoJul 19, 2007
  12. Adam HayekJul 19, 2007
  13. Andy ParkinsJul 19, 2007
  14. Johannes SchindelinJul 19, 2007
  15. Andy ParkinsJul 19, 2007
  16. Linus TorvaldsJul 19, 2007
  17. Junio C HamanoJul 20, 2007
  18. Shawn O. PearceJul 20, 2007
  19. Linus TorvaldsJul 19, 2007
  20. Johannes SchindelinJul 19, 2007
  21. Olivier GalibertJul 19, 2007
  22. Linus TorvaldsJul 19, 2007
  23. Wincent ColaiutaJul 19, 2007
  24. Johannes SchindelinJul 19, 2007
  25. Sven VerdoolaegeJul 19, 2007
  26. 3/6 Add git-notesJohannes Schindelin, Jul 15, 2007
  27. Junio C HamanoJul 16, 2007
  28. 3/6 Add git-notesJohannes Schindelin, Jul 19, 2007
  29. Johannes SchindelinJul 19, 2007
  30. 4/6 Add a test script for "git notes"Johannes Schindelin, Jul 15, 2007
  31. Junio C HamanoJul 16, 2007
  32. 4/6 Add a test script for "git notes"Johannes Schindelin, Jul 19, 2007
  33. 5/6 Document git-notesJohannes Schindelin, Jul 15, 2007
  34. 6/6 notes: add notes-index for a substantial speedup.Johannes Schindelin, Jul 15, 2007
  35. Johannes SchindelinJul 15, 2007
  36. Shawn O. PearceJul 16, 2007
  37. Johannes SchindelinJul 16, 2007
  38. Andy ParkinsJul 16, 2007
  39. Junio C HamanoJul 16, 2007
  40. Johannes SchindelinJul 16, 2007
  41. Junio C HamanoJul 16, 2007
  42. Johannes SchindelinJul 19, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.