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

Verifying the whole repository

From
ABAlex Bennee <kernel-hacker@bennee.com>
Date
Oct 23, 2008, 13:59 UTC
Message-ID
<b2cdc9f30810230659n15f44f64l571a0df3dbe104d9@mail.gmail.com>
Hi,

While I was debugging a crash in parsecvs while converting our CVS repository I discovered it was because one of the CVS files had become corrupted (truncated). This is a problem I've had before with RCS based files which are prone to silent corruption that you won't notice until you try and checkout an old revision of the file.

As git is fundamentally hash based it's a lot easier to determine the health of the repository but I wonder if it's possible for silent corruption to creep in which won't be noticed until you try and checkout a historical commit of the tree. I notice there is a git-verify-pack command that checks the pack files are OK. Do any of the other commands implicitly ensure all objects in the repo are correct and valid? git-gc?

Are there any other parts of the .git metadata that are crucial or is it enough to say if all objects and packs match their hashes you have all the information you may need to recover an arbitrary revision of the repo?

-- 
Alex, homepage: http://www.bennee.com/~alex/
Next: David Symonds
Message 1 of 4 in “Verifying the whole repository”
  1. Alex BenneeOct 23, 2008
  2. David SymondsOct 23, 2008
  3. Alex BenneeOct 23, 2008
  4. Shawn O. PearceOct 23, 2008

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.