Am 06.02.22 um 10:00 schrieb Gamblin, Todd: >> I don't think there is an obvious cross-check for the tarball sha1 >> comparison with the release tag's sha1, if that's the question. > > This is pretty much the question — does git do an integrity check on > clone to verify that the commit hash (and its tree hash) are valid? > Does git verify objects as they’re written to disk when it’s cloning a repo? Yes, it does. (How could you even contemplate that it does not? It is the most obvious way to protect the cloner.) Granted, `git clone` first writes objects (actually, packs) to the disk before it checks them, but I don't think that this detail is important. >> The tag contains the sha1 hash of the release commit, which in turn >> contains the sha1 hashes of the tree that is being released, and the >> previous commit in the git history, and onward the hashes roll... > > It seems like git fsck is supposed to check all of these, so would > that be the potential analog? It seems like overkill if all I really > want is the integrity of one commit snapshot. Would it be sufficient to > heck the hash of the checked out commit and then to check its tree hash… > I guess I’m just curious why git doesn’t have a command that verifies > the integrity of the current working tree against its commit sha1. That command is pretty much 'git status --ignored': if it shows anything but "nothing to commit, working tree clean", your worktree is different from the commit. The point is, there certainly are commands that let you check a worktree against a commit. -- Hannes
