On the issue of corruption
Yes, you are missing something. Namely, you did not damage the file in the way that attention is paid to Git. An object stored on disk usually begins with the type of object, followed by a space, followed by a size (using ASCII numbers), followed by NUL. Size determines how large the object is, and that all that Git ends with reading. Thus, binding data to an end like this will not actually damage the object. If you replaced the contents of the file with something else, you will see a problem.
For more information about the object, see the Git User Guide :
Object storage format
All objects have a statically defined type that identifies the format of the object (i.e. how it is used and how it can refer to other objects). There currently are four different types of objects: blob, tree, commit, and tag.
Regardless of the type of object, all objects have the following characteristics: they are all reset using zlib and have a header that not only determines their type, but also provides information about the size of the data in the object. It is worth noting that the SHA-1 hash, which is used to designate an object, is the hash of the original data plus this header, so the sha1sum file does not match the object's file name.
As a result, the general consistency of an object can always be checked regardless of the content or type of the object: all objects can be confirmed by checking that (a) their hashes correspond to the contents of the file and (b) the object is successfully inflated to a stream of bytes, which forms a sequence <ascii type without space> + <space> + <ascii decimal size> + <byte\0> + <binary object data> .
Structured objects can additionally have their own structure and the ability to connect to verified other objects. This is usually done using the git fsck program, which generates a complete dependency graph of all objects and checks their internal ones (in addition to simply confirming their surface consistency through a hash).
However, there is an interesting interaction that makes me think that git fsck should work more intensively and notice when there is garbage in the file at the end. If you try to run git gc in this repo, you will see an error similar to this:
:: git gc Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. error: garbage at end of loose object '45b983be36b73c0788dc9cbcb76cbb80fc7bb057' fatal: loose object 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 (stored in .git/objects/45/b983be36b73c0788dc9cbcb76cbb80fc7bb057) is corrupt error: failed to run repack
It seems that if git gc cannot be started, then git fsck should catch the problem.
Why you do not see the "Object Check"
This problem is actually very simple: there are no packed objects to scan. Those live in .git/objects/pack . If you do not have any of these files, you will not see the “Scan Objects” bit.