When I try to trigger git pull command it is returning an error as follows:
mert@eren-VirtualBox:~/restoranya/restoranya$ git pull origin master
error: object file
.git/objects/2a/0836034919f0cfe0f8f1ab98037884dd1c93de is empty
fatal: loose object 2a0836034919f0cfe0f8f1ab98037884dd1c93de (stored
in
.git/objects/2a/0836034919f0cfe0f8f1ab98037884dd1c93de) is corrupt
mert@eren-VirtualBox:~/restoranya/restoranya$ fatal: The remote end
hung up unexpectedly
Whats the reason for such an error? What should I do to recover?
For some reason, that object is corrupt in your origin remote.
You need another clone of this repository where you can run
git cat-file -t 2a0836034919f0cfe0f8f1ab98037884dd1c93de
with no error, and you want to inject a good version of that object into origin’s object database.
Describing the fix can be a tricky because we are talking about multiple clones that may reside on different hosts and possibly owned by different users. The steps below assume that you have shell access to the host of your origin as the user that owns your origin repository. The prompt origin$
below indicates commands to be run on the machine that hosts your origin.
The bad object on origin is in loose format, so the final step of the restore is a simple copy.
Assuming the object in the good clone is also loose, then run
origin$ cp /path/to/good-repo/.git/objects/\
2a/0836034919f0cfe0f8f1ab98037884dd1c93de \
/path/to/origin/objects/2a
if your origin is a bare repository or
origin$ cp /path/to/good-repo/.git/objects/\
2a/0836034919f0cfe0f8f1ab98037884dd1c93de \
/path/to/origin/.git/objects/2a
otherwise.
If in the good clone this object is stored in a pack, then you have to get it out. I recommend doing this in a scratch throw-away clone.
origin$ git clone file:///path/to/good-repo /tmp/restore-repo
If good-repo
is on another machine, the clone URL will be different.
origin$ git clone user@other-machine:src/foo/.git /tmp/restore-repo
Change to the directory that holds your temporary repository.
origin$ cd /tmp/restore-repo
Move the pack files out of the object database because git won’t unpack the objects if it thinks it already has them.
origin$ mkdir /tmp/restore-packs
origin$ mv .git/objects/pack/* /tmp/restore-packs
Now you’re ready to unpack.
origin$ for pack in /tmp/restore-packs/*.pack; do
git unpack-objects -r < $pack
done
The -r
option tells git-unpack-objects
to continue unpacking even if it encounters a bad object.
At this point, /tmp/restore-repo
should now contain 2a08360… as a loose object, so run
origin$ cp /tmp/restore-repo/.git/objects\
2a/0836034919f0cfe0f8f1ab98037884dd1c93de \
/path/to/origin/objects/2a
or
origin$ cp /tmp/restore-repo/.git/objects\
2a/0836034919f0cfe0f8f1ab98037884dd1c93de \
/path/to/origin/.git/objects/2a
depending on whether origin is a bare repository.
Did you try a repack ?
git-repack is used to combine all objects that do not currently reside in a "pack",
into a pack. It can also be used to re-organize existing packs into a single, more
efficient pack.
A pack is a collection of objects, individually compressed, with delta compression
applied, stored in a single file, with an associated index file. Packs are used
to reduce the load on mirror systems, backup engines, disk storage, etc.
there is some command for cleaning your repo..
$ git-prune
$ git-gc --aggressive
$ git-repack
$ git-repack -a
$ git-prune-packed