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

Re: My git repo is broken, how to fix it ?

From
Nicolas Pitre <nico@cam.org>
Date
Mar 22, 2007, 16:34 UTC
Message-ID
<alpine.LFD.0.83.0703221215150.18328@xanadu.home>
In-Reply-To
<Pine.LNX.4.64.0703220847540.6730@woody.linux-foundation.org>
On Thu, 22 Mar 2007, Linus Torvalds wrote:
> Ok, apart from #1, those should be in current -git now, along with better 
> validation checks (by Nico) when packing. So hopefully at least when there 
> is corruption in a loose object, we will now always notice when we do a 
> "git repack", and will never generate a broken pack-file. Knock wood.

Not yet actually. What I did do is to make index-pack perform more validation and ensure it never accept SHA1 collisions.

For the repack case... I think there should be a better way. Either we revalidate the full SHA1 which would be expensive as we'd basically lose most advantages of direct pack data copy.

What I'm pondering is some sort of lightweight checksum like adler32 for object data in the pack but stored in the index. Since index-pack already perform the full SHA1 already, it could as well provide a checksum for the raw pack object data for the repack case. Currently we try to validate reused pack data by attempting an inflate pass on the object payload, but that doesn't validate the object type nor the reference SHA1 to delta base objects which could get corrupted and copied without noticing into another pack.

Show 5 quoted lines
> Of course, I actually wonder if the bug might be in your version of zlib 
> (miscompiled or some other thing), in which case *any* amount of 
> pre-validation won't really help, because it will become corrupted when we 
> deflate it prior to writing. For example, if "deflateBound()" sometimes 
> doesn't give a valid upper bound and we allocate too little space..

Well, since we provide the size of the allocated output buffer to zlib it would be seriously broken if it overflowed it. Also zlib perform a checksum verification of the deflated data if I remember correctly. So it seems to me that zlib should be quite self validating already.

Nicolas
Previous: Linus TorvaldsNext: Linus Torvalds
Message 13 of 28 in “My git repo is broken, how to fix it ?”
  1. Alexander LitvinovFeb 28, 2007
  2. Linus TorvaldsFeb 28, 2007
  3. Alexander LitvinovFeb 28, 2007
  4. Linus TorvaldsFeb 28, 2007
  5. Alex RiesenFeb 28, 2007
  6. Alexander LitvinovMar 19, 2007
  7. Linus TorvaldsMar 19, 2007
  8. Linus TorvaldsMar 20, 2007
  9. Alexander LitvinovMar 20, 2007
  10. Junio C HamanoMar 20, 2007
  11. Nicolas PitreMar 20, 2007
  12. Linus TorvaldsMar 22, 2007
  13. Nicolas PitreMar 22, 2007
  14. Linus TorvaldsMar 22, 2007
  15. Linus TorvaldsMar 22, 2007
  16. Linus TorvaldsMar 22, 2007
  17. Nicolas PitreMar 22, 2007
  18. Linus TorvaldsMar 22, 2007
  19. Nicolas PitreMar 22, 2007
  20. Jeff KingMar 22, 2007
  21. Linus TorvaldsMar 23, 2007
  22. Bill LearMar 23, 2007
  23. Jeff KingMar 23, 2007
  24. git-apply: Do not free the wrong buffer when we convert the data for writeoutJunio C Hamano, Mar 22, 2007
  25. Linus TorvaldsMar 22, 2007
  26. Alexander LitvinovMar 23, 2007
  27. Alexander LitvinovMar 23, 2007
  28. Johannes SixtMar 22, 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.