Purpose

The purpose of this KB article is to provide context as to why this error message may occur in GIT, and provide some solutions to resolve the issue.

Diagnosis

You are attempting to push a commit to a remote repository, but are met with some variant of the following error message:

fatal: unable to read 18d62d26762787ca2d00bca6eabcba76023019c1
aborting due to possible repository corruption on the remote side.
git upload-pack: git-pack-objects died with error.

Cause

• When a file is not written properly to the GIT object database, either because of a hardware/network failure or another issue - this can result in potential repository corruption
• The issue is GIT related and is not Bitbucket-specific, as such it can occur on any SCM that uses GIT

The first step will be to identify exactly where the potential corruption is, you can do so by running a GIT file system integrity check command locally and observing the results:

# git fsck --full --strict
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1394358/1394358), done.
broken link from    tree 98068c4d5f2513ada367ac2a5979e3ac238dd911
              to    blob 18d62d26762787ca2d00bca6eabcba76023019c1

Once you have the resulting error (usually an issue with the GIT working tree as above), you can begin to resolve the issue.

Solution(s)

There are a few ways to resolve an issue such as the above.

Solution #1 - Attempt to repair the object database

1. As you have the tree/blob details from the file system check command above, you can use this to check the tree that the blob belongs to and find the filename of that specific blob from the list of blobs within the tree:

   # git ls-tree 98068c4d5f2513ada367ac2a5979e3ac238dd911
   blob 18d62d26762787ca2d00bca6eabcba76023019c1 code.java

2.  Once you have tracked down the problematic file in the list, you can attempt to have GIT locate the unique SHA-1 hash that belongs to that file and write it to the object database (with the -w switch):
   

   git hash-object -w code.java

   
   

3. If a SHA-1 hash is returned by the above command, the issue is resolved and a subsequent file system check will reveal this.
   

If this solution did not fix the issue, please continue to Solution #2 (if working as part of a team) or Solution #3 (if you are not on a team).

Solution #2 - Force push 

There is a chance that a member of your team has a working copy of the local repository prior to the corruption, and fixing the missing blob(s) is as easy as pushing these back to the repository.

1. Consult with your team and ask them to execute the same file checking command against their local repository:

   # git fsck --full --strict

2. If they do not receive any errors, they can force push their working copy of the local repository up to the remote repository to resolve the issue (perform a clone backup of the repository first just in case):

   # git push -f origin --all

3. Once the push completes, you and any other colleagues with the error displayed previously can then perform a fresh clone of the repository and verify once again with the file system checking command that there are now no errors present.

Solution #3 - Restore from backup

If all other avenues fail, the support team is able to restore a backup copy of your repository.

• As per our backup policy we maintain repository backups for 7 days, and these consist of hourly snapshots of your core repository content.

• Please feel free to raise a support ticket or raise a community support ticket and we can restore your repository prior to the corruption issue.

NOTE: This option is time sensitive, so you will need to make the decision to restore within this 7-day period to avoid any potential data loss.