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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
