git log works fine and provides:
commit ac1d9fec39372683cd20fba15f9c5318b957cf25 (HEAD -> master)
Author: TryerGit <Email@Email.com>
Date: Tue Apr 5 20:17:36 2022
Writeup per suggestion
commit e6cdf4125529fcb8c0b0e131b12c4ab24012cdfd (origin/master)
Author: TryerGit <Email@Email.com>
Date: Mon Apr 4 11:54:53 2022
B4 trying folder specific .gitignore files
commit 54a753a762a7cdfbdea9a0d50deef3b886712cc3
Author: TryerGit <Email@Email.com>
Date: Sat Mar 26 17:32:24 2022
Functionally OKAYish version
... and so on
git reflog works fine and provides:
ac1d9fe (HEAD -> master) HEAD@{0}: commit: Writeup per suggestion
e6cdf41 (origin/master) HEAD@{1}: commit: B4 trying folder specific .gitignore files
54a753a HEAD@{2}: commit: Functionally OKAYish version
... and so on
However, git status gives the error:
error: bad tree object HEAD
How can this error be fixed?
ETA: git fsck says:
Checking object directories: 100% (256/256), done.
Checking objects: 100% (2338/2338), done.
error: 6e6758bea668ae2fb6271dec137927981548b581: invalid sha1 pointer in cache-tree
broken link from commit ac1d9fec39372683cd20fba15f9c5318b957cf25
to tree 6e6758bea668ae2fb6271dec137927981548b581
missing tree 6e6758bea668ae2fb6271dec137927981548b581
dangling tree 3771f5b131b8934d28373230375c76658c93c0c8
>Solution :
This is the result of having a bad tree object, namely 6e6758bea668ae2fb6271dec137927981548b581. The object itself either does not exist at all, or is invalid internally; the git fsck output implies the former.
It’s not clear how you got into this situation, but git log by itself never notices because it obtains commit ac1d9fec39372683cd20fba15f9c5318b957cf25 which itself is intact. It’s just that this commit refers to the missing tree object. As long as the software never tries to retrieve the missing object, nobody notices that it is missing. The bad (because-of-missing-tree, but not bad on its own) commit also refers to previous commit e6cdf4125529fcb8c0b0e131b12c4ab24012cdfd, which is good all the way around, and all previous commits are fine.
If you can find or re-create the missing tree object, the repository will be restored to usability. Alternatively, if you can replace the bad commit with a good one that refers to an existing or new tree object, the repository as a whole will be OK, although the stored snapshot that went with commit 6e6758bea668ae2fb6271dec137927981548b581 is gone.