TL;DR
This issue mainly occurs when the object hash is invalid or hash does not located in .git/objects/../
. This also can be caused by a third-party synchronization program such as Dropbox, Google Drive, etc. If remote branch was broken, you can face this issue too. The Error message is:
error: invalid object 100644 *commit hash* for '*file_name*' error: Error building trees
To fix this, you can approach with the following steps:
Solution 1: Standard Approach
# Find the broken object
git fsck --full
# Regenerate object hash
git hash-object -w {path of the broken object}
# Commit again
git add . ; git commit -m "{commit message}"
Solution 2: Reset Index of Objects
- If there are lots of broken object or you can’t find the broken object, you can reset the index of objects.
# Reset index of objects
git rm -r --cached .
# Stage files
git add .
# Commit again
git commit -m "{commit message}"
Solution 3: For user of third-party syncronization program
- If you are using a third-party syncronization program, you should exclude
.git
folder from the syncronization. - Then try solution 1 or 2.
Solution 4: For those who can’t point out any cause, Reset the previous commit
# Check reference of git log
git reflog
# Reset to the previous commit
git reset --hard HEAD@{1}
# Commit again
git add . ; git commit -m "{commit message}"
Solution 5: For whose remote branch is broken
- Try this solution with full caution. This will change your commit history.
# Remove remote repositiory from local and add again
git remote remove origin
git remote add origin {remote_repository_url}
git fetch origin
git reset --hard origin/{branch with no error}
Reason of the Issue
Git tracks data with objects and the objects are connected with reference. If objects itself is broken or object refers to the wrong object, Git can not build the tree. This kind of damage can caused by multiple reasons.
Therefore, to solve this issue, you should point out the broken object first.
More Details for Solutions Above
git fsck
To check integrity of git objects, you can run git fsck
, stands for File System ChecK. The command let you know broken objects which could be commit, blob, tree, etc.
git hash-object -w
If you find the broken object, you can use git hash-object -w {path of the broken object}
to generate object hash. This will create a new object hash for the broken object, and it will connect the object to the tree.
git rm -r --cached .
Yet if there are too many broken objects or you can’t find the broken object, you can reset index of object hashes with git rm -r --cached .
. Then regenerate object hashes with git add .
or git add {file_name}
. This was my case and it worked. - git rm -r --cached .
detaches all references of blob objects, which can be potentially broken. Even if the objects are remain in the local repository, wrong references will turns to an unreachable state. After the process, you can regenerate the object hash with git add .
or git add {file_name}
. - Detached references by run git rm --cached
will be removed when you run git gc
or git prune
.
git reflog
If you are not sure about the broken object, you can check the reference of the git log with git reflog
. This will show you the history of the commits. You can reset to the previous commit with git reset --hard HEAD@{1}
.
For those who use third-party syncronization program
If necessary, prevent the cause of the issue; such as third-party syncronization program. Exclude .git
folder from the syncronization. - Unfortunately, whether you do not use any of third-party program, the git object could be broken by OS, hardware, etc. In this case, recovering from the backup is the best solution. - If you doesn’t have any backup, read this: Recovering from repository corruption