Q:

Inner workings of Git integrity check

After reading this, and looking around at the git source a little bit, I have a question regarding the innerworkings of the git integrity check.  The reference makes claim that it's not possible to change a git commit without git knowing about it.  Also, git stores commits as snapshots instead of as deltas, so there isn't any cross commit dependency that I am aware of in the hash value.  
So my question is this, is it possible for someone to potentially delete the last commit they made (without undoing the code changes made) without anybody, including Git itself, knowing about it?  How about a commit somewhere in the middle?

A:

Every git object is identified by an SHA-1.  This is a cryptographic checksum of the object's type and contents.
Here is an example commit object (a real, actual commit), with ID 5f95c9f850b19b368c43ae399cc831b17a26a5ac:
tree 972825cf23ba10bc49e81289f628e06ad44044ff
parent 9c8ce7397bac108f83d77dfd96786edb28937511
author Junio C Hamano <gitster@pobox.com> 1392406504 -0800
committer Junio C Hamano <gitster@pobox.com> 1392406504 -0800

Git 1.9.0

Signed-off-by: Junio C Hamano <gitster@pobox.com>

If you change some part(s) of this commit, you will need to make its checksum come out to 5f95c9f850b19b368c43ae399cc831b17a26a5ac to fool git into believing it's the same commit, even though it's different.  Although this is theoretically possible (due to the pigeonhole principle), it's not something you can just come up with off-hand (and in fact no SHA-1 collisions have ever been observed, as far as I know: 2160 is a very big number, even with the birthday problem in mind).
Note that the tree associated with this commit is 972825cf23ba10bc49e81289f628e06ad44044ff.  Its contents are too long to reproduce entirely but they begin like this:
100644 blob 5e98806c6cc246acef5f539ae191710a0c06ad3f    .gitattributes
100644 blob b5f9defed37c43b2c6075d7065c8cbae2b1797e1    .gitignore
100644 blob 11057cbcdf4c9f814189bdbf0a17980825da194c    .mailmap
100644 blob 536e55524db72bd2acf175208aef4f3dfc148d42    COPYING
040000 tree 47fca99809b19aeac94aed024d64e6e6d759207d    Documentation
100755 blob 2b97352dd3b113b46bbd53248315ab91f0a9356b    GIT-VERSION-GEN

This tree lists the files, along with their SHA-1s.  The ID of this tree is the checksum of its contents, including all the IDs of all the sub-trees and blobs.
If you wish to change the tree associated with the commit, you will have to change some blob(s) and/or subtree(s).  The new blobs will have different IDs, which will change the top level tree ID, which will change the string after the word tree in the commit, which will change the ID of the commit.
If you wish to remove an earlier commit from the overall commit graph, you will have to change the commit-ID following the word parent in some child commit.  This means you have to change that commit's ID, and this change will bubble through all subsequent commits, changing the branch-tip commit's ID.  (This is why rebasing code that others depend on causes them so much heartburn.)
These interlinked IDs form what is called a Merkle tree.  This is what allows the security claim.

