git log
works fine and provides:
commit ac1d9fec39372683cd20fba15f9c5318b957cf25 (HEAD -> master)
Author: TryerGit <[email protected]>
Date: Tue Apr 5 20:17:36 2022
Writeup per suggestion
commit e6cdf4125529fcb8c0b0e131b12c4ab24012cdfd (origin/master)
Author: TryerGit <[email protected]>
Date: Mon Apr 4 11:54:53 2022
B4 trying folder specific .gitignore files
commit 54a753a762a7cdfbdea9a0d50deef3b886712cc3
Author: TryerGit <[email protected]>
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
ETA2: A cloud based synching mechanism creates folders in .git/objects/
in case of clash as, say, fa (2)
if fa
is currently synching or something along those lines. So, I navigated into the .git/objects/
folder and renamed fa (2)
back to fa
. In case there was both fa
and fa (2)
folders present, I navigated into each of these folders and deleted the folder whose contents were older. Then, the remaining folder, I renamed it back to fa
. After doing this for all folders in .git/objects/
that had duplicated entries, running git fsck
returns:
Checking object directories: 100% (256/256), done.
Checking objects: 100% (2338/2338), done.
and no errors seemingly indicating that all is well. git status
no longer returns any errors. This may or may not work in your case. Please see torek's comment here
CodePudding user response:
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.