Re: Commit SHA1 == SHA1 checksum?
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Feb 6, 2022, 10:23 UTC
- Message-ID
- <06e09df2-5fa5-8ce8-4cbe-4918d5dbaa25@kdbg.org>
- In-Reply-To
- <188C988E-F679-4AD6-AA04-E51F11F7D9A7@llnl.gov>
Am 06.02.22 um 10:00 schrieb Gamblin, Todd:
Show 6 quoted lines
>> 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.
Show 10 quoted lines
>> 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