Git missing blob isn't really missing

error: e82fe20e35ac4cda5dad3369abf3984d6280224d: object corrupt or missing: 
    ./objects/e8/2fe20e35ac4cda5dad3369abf3984d6280224d

"object corrupt or missing". The file is there, but its checksum does not match the filename.

And when I try to get the original file from my colleague I get the correct hash

The checksum of your colleague's file matches its filename.

how to fix it?

Copy your colleague's file to your repository.

However, I don't understand how what happened.

It's a file on disk, any number of things could have happened. A disk error. An overzealous anti-virus. A bug in Git.

One major culprit would be if your repository is on any sort of shared drive such as Dropbox. A Git repo cannot be safely used on a shared drive.

• Run a check on your disk.
• Make sure Git is up to date.
• Check your anti-virus didn't try to protect you against your Git repo.
• Move your repo off a shared drive.
• If your repo is on Dropbox, use git-remote-dropbox.

Note the error message evolves and is more precise with Git 2.34 (Q4 2021), "git fsck"^(man) has been taught to report mismatch between expected and actual types of an object better.

See commit 96e41f5, commit 31deb28, commit dccb32b, commit 5848fb1, commit 3b6a8db, commit 01cab97, commit ddb3474, commit bfff2c4, commit 74ad250, commit dd45a56, commit 7e7d220, commit 59b8283, commit 70e4a57, commit a5ed333, commit 42cd635, commit f7a0dba, commit 093fffd (01 Oct 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 061a21d, 25 Oct 2021)}

fsck: report invalid object type-path combinations

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Improve the error that's emitted in cases where we find a loose object we parse, but which isn't at the location we expect it to be.

Before this change we'd prefix the error with a not-a-OID derived from the path at which the object was found, due to an emergent behavior in how we'd end up with an "OID" in these codepaths.

Now we'll instead say what object we hashed, and what path it was found at.
Before this patch series e.g.:

$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ mv objects/e6/ objects/e7

Would emit ("[...]" used to abbreviate the OIDs):

git fsck
error: hash mismatch for ./objects/e7/9d[...] (expected e79d[...])
error: e79d[...]: object corrupt or missing: ./objects/e7/9d[...]

Now we'll instead emit:

error: e69d[...]: hash-path mismatch, found at: ./objects/e7/9d[...]

Furthermore, we'll do the right thing when the object type and its location are bad.
I.e.
this case:

$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ mv objects/83 objects/84

As noted in an earlier commits we'd simply die early in those cases, until preceding commits fixed the hard die on invalid object type:

$ git fsck
fatal: invalid object type

Now we'll instead emit sensible error messages:

$ git fsck
error: 8315[...]: hash-path mismatch, found at: ./objects/84/15[...]
error: 8315[...]: object is of unknown type 'garbage': ./objects/84/15[...]

In both fsck.c and object-file.c we're using null_oid as a sentinel value for checking whether we got far enough to be certain that the issue was indeed this OID mismatch.

This will make the fix easier to apply.