fatal: bad object xxx

[Edit 1, 19 Nov 2016] While this would sometimes indicate repository corruption, it turns out to occur on Windows when some command—usually, another Git in another task—is holding internal files open and locked. In this case, terminating the other task should fix it. Original answer is below.

[Edit 2, 6 May 2020] Suppose xxx above resembles, e.g., b34789c0b0d3b137f0bb516b417bd8d75e0cb305 (a raw hash ID). If you got this from cut-and-paste, be sure that it's for this repository (it's easy to grab a hash ID from some other repository without realizing it, especially if you have multiple windows open). If you retyped it yourself, be sure there aren't any typos. If this involves submodules, make sure the submodule is up to date. See the comments on the question and some of the answers, including this one.

bad object with some hexadecimal number tends to mean that a tag has an invalid reference number in it, but can also occur for a few other strange cases. For instance, if I do a:

$ git tag foo
$ vi .git/refs/tags/foo

and change the last character (in this case from 6 to 5) and write that out:

$ git log foo
fatal: bad object foo

What exactly is the xxx here and where did it come from?

I don't know the exact reason why that happens. For me, it's because I forget to pull the entire repository to my local. I have 2 or more path, and each path pulls from different branch

/path/branch_a/ -> pulled from branch A
/path/branch_b/ -> pulled from branch B

on branch A, I made a few modification, and commit as usual. I want that commit (for example the commit ID is abcdef123) appears on branch B, so I use

$ cd /path/branch_b/
$ git branch
master
branch_a
* branch_b


$ git cherry-pick abcdef123

This gives me that kind of error. So I need to pull the entire repository before getting that commit

$ git pull
remote: Counting objects: 257, done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 216 (delta 187), reused 186 (delta 158)
Receiving objects: 100% (216/216), 53.13 KiB | 43 KiB/s, done.
Resolving deltas: 100% (187/187), completed with 38 local objects.
From github.com:username/my_repo
abcdef3..80c0d68  branch_a    -> origin/branch_a
Already up-to-date.


$ git cherry-pick abcdef123
[branch_b ccddeef] Some commit message
1 file changed, 1 insertion(+), 1 deletion(-)

In my case I was cherry-picking from another branch which I didn't pull, but I tried to copy commit's IDs from GH (I haven't got this on my local where I was cherry-picking).

Hope it helps ;-D

I just ran into the same error (bad object [hash]) while attempting to merge from a branch my client didn't know about. (Similar to PrzeoR's case, but instead of needing a pull I needed to fetch)

In my case I needed to run git fetch to re-sync my client to the state of the server. Posting this here in case anyone reaches this thread the same way I did and could benefit from this insight.

git pull
git cherry-pick [hash]
fatal: bad object [hash]
git fetch
remote: Counting objects: 8, done. (etc.)
From github.com:repo/branch
* [new branch] branchname


git cherry-pick [hash]
[success]

Objects that don't exist in the repository give that error message

E.g.:

 git init
touch a
git add a
git commit -m 0
# This object is not in the repository.
git show 1111111111111111111111111111111111111111

As for what causes the problem, it is hard to say without a minimal reproducible example.

Submodule woes have given me that error once.

I ran into the same error when trying to cherry-pick (on A) the commit of another branch ( B). Issue was stupid, simply forgot to git push the commit (B).

you need to do git fetch to get the latest commits in sync with local

git fetch

then do

git revert

The reason I ran into it was simple. I was switching back and forth between the main repository and a submodule. I tried to do a diff between one hash (in the main repository) and another that I copied from SourceTree, thinking it was an easy to get the old HEAD (I had regressed one revision to track down a regression). The old HEAD hash I grabbed was that of a submodule, and git diff was put out with me for feeding it garbage. That's how I ended up here, and that's when I realized it was operator error. If your hash is from a different repository git will scold you with this message. However, if you do feed it garbage, would it not be better to report "XXX not a revision in this repository"? It is every bit as general an error message as "bad object" and quite a bit less likely to send someone to stack overflow for answers. I wonder if the folks in the git community would accept that pull request...

I got this error while trying to cherry-pick a commit whose hash I had copied from GitHub. This commit was on a branch that I hadn't pulled, just like PrzeoR.

Unlike PrzeoR a git fetch didn't help at first because the branch had been deleted on GitHub. Fortunately I was able to find the corresponding (closed) Pull Request and to restore the branch on GitHub.

git pull

OR

git fetch origin

Reason: If the commit id which you are trying to cherry pick is not available in your local git, then there is a possible of this error.

Doing a git pull will fix this. If this hasn't been fixed, ask the person who has shared the commit id to push the change to origin and do a git pull

git fetch --all

The git fetch command downloads commits, files, and refs from a remote repository into your local repository.

This issue can arise when there's an outdated or corrupted branch stored locally.

Deleting the file .git/refs/remotes/origin/xxx (after making a backup!) then fetching a fresh copy from the server worked for me.

More detail at GitHub.

I'm not sure how i got this error, This is the error i got.

fatal: bad object refs/remotes/origin/{branchname}
fatal: failed to run repack

Tried pruning the git repo via git gc --aggressive --prune=now. It did not help.

This branch was stale and it was not important for me so i deleted the branch folder

rm -rf .git/refs/remotes/origin/{branchname}

ran git gc

It did object Enumeration and clean successfully.

As @jxramos wrote in a comment, this could be due to using a shallow clone in which case the hash you are refering might correspond to a commit which was not fetched by the shallow clone.

We got this message when migrating tests to a Gitlab CI which by default uses a shallow clone with a depth of 20.