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

Re: Mozilla .git tree

From
Nicolas Pitre <nico@cam.org>
Date
Aug 30, 2006, 05:53 UTC
Message-ID
<Pine.LNX.4.64.0608300124550.9796@xanadu.home>
In-Reply-To
<20060830031029.GA23967@spearce.org>
On Tue, 29 Aug 2006, Shawn Pearce wrote:
Show 9 quoted lines
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > The git tools can be modified to set the compression level to 0 before
> > compressing tree deltas. There is no need to change the decoding code.
> > Even with compression level 0 they still get slightly larger because
> > zlib tacks on a header.
> 
> See my followup email to myself; I think we're talking a zlib
> overhead of 9.2 bytes on average per tree delta.  That's with a
> compression level of -1 (default, which is 6).

In fact, the bulk of a tree delta is most likely to contain the literal sha1 of one or more directory entries that changed, and this is hardly compressible. There is nothing to gain by forcing zlib level to 0 for tree deltas since it never makes the deflated stream smaller from the tests I've performed in the past. It seems that zlib is smart enough not to attempt any compression when there is no gain. That leaves the zlib header as the only overhead.

And the zlib header contains a CRC which we're about to use for validating the data when doing delta data reuse in order to prevent pack corruption propagation like the one recently posted on the list. Without that a pack corruption (from a bad disk sector for example) is likely to go unnoticed when doing a repack. The data could be validated by expanding deltas and verifying the sha1 on the end result but this is a really expensive operation if performed on all deltas which is best left to git-fsck-objects --full. So I think the small overhead relative to total pack size might be worth it for better data integrity.

Using an offset instead of a sha1 to reference a delta base object is certainly a good idea though. But I'd use the same variable encoding as the object size to avoid the 32-bit limit issue. When generating a thin pack the real sha1 of the delta object could be substituted for the offset quite easily if the base object is not sent a part of the same pack.

Nicolas
Previous: Jon SmirlNext: Junio C Hamano
Message 6 of 52 in “Re: Mozilla .git tree”
  1. Shawn PearceAug 30, 2006
  2. Shawn PearceAug 30, 2006
  3. Jon SmirlAug 30, 2006
  4. Shawn PearceAug 30, 2006
  5. Jon SmirlAug 30, 2006
  6. Nicolas PitreAug 30, 2006
  7. Junio C HamanoAug 30, 2006
  8. Junio C HamanoSep 1, 2006
  9. Shawn PearceSep 2, 2006
  10. Junio C HamanoSep 2, 2006
  11. Shawn PearceSep 2, 2006
  12. Junio C HamanoSep 2, 2006
  13. Jon SmirlSep 2, 2006
  14. Shawn PearceSep 2, 2006
  15. Linus TorvaldsSep 2, 2006
  16. Junio C HamanoSep 2, 2006
  17. Shawn PearceSep 2, 2006
  18. Shawn PearceSep 2, 2006
  19. Junio C HamanoSep 2, 2006
  20. Shawn PearceSep 2, 2006
  21. Junio C HamanoSep 2, 2006
  22. Shawn PearceSep 3, 2006
  23. A Large Angry SCMSep 1, 2006
  24. Linus TorvaldsSep 1, 2006
  25. Junio C HamanoSep 1, 2006
  26. pack-objects: re-validate data we copy from elsewhere.Junio C Hamano, Sep 1, 2006
  27. Linus TorvaldsSep 2, 2006
  28. VGER BF report?Johannes Schindelin, Sep 2, 2006
  29. Sam RavnborgSep 2, 2006
  30. Junio C HamanoSep 2, 2006
  31. Junio C HamanoSep 2, 2006
  32. Shawn PearceSep 2, 2006
  33. Junio C HamanoSep 2, 2006
  34. Linus TorvaldsSep 2, 2006
  35. Junio C HamanoSep 2, 2006
  36. Shawn PearceSep 2, 2006
  37. Junio C HamanoSep 3, 2006
  38. Shawn PearceSep 4, 2006
  39. Junio C HamanoSep 4, 2006
  40. Shawn PearceSep 4, 2006
  41. Junio C HamanoSep 4, 2006
  42. Linus TorvaldsSep 3, 2006
  43. Junio C HamanoSep 3, 2006
  44. Junio C HamanoSep 5, 2006
  45. Linus TorvaldsSep 2, 2006
  46. Junio C HamanoSep 2, 2006
  47. Junio C HamanoSep 3, 2006
  48. Linus TorvaldsSep 3, 2006
  49. Linus TorvaldsSep 3, 2006
  50. Junio C HamanoSep 3, 2006
  51. Junio C HamanoSep 4, 2006
  52. Linus TorvaldsSep 4, 2006

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.