fatal: bad object xxx

Question

I tried reverting to a previous git commit with:

git revert xxx

I'm now receiving this error as a response:

fatal: bad object xxx

What am I doing wrong? How do I fix this?

I would like to help future readers by pointing out that if you get this error you might be in the wrong directory/repo. I was trying to get the tag or branch of a submodule commit without descending into the submodule’s subdirectory. And I was pasting the commit hash from git diff on the super repo so “It MUST exist!” — cardiff space man
– cardiff space man, Commented Jan 14, 2020 at 21:38

Prabowo Murti · Accepted Answer · 2013-08-20 08:32:21Z

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(-)

This answer reveals a common mistake using same repo in different folders with different branches. A +1 for me.

torek · Accepted Answer · 2020-05-06 16:26:03Z

[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?

OK, so, it's a 40-character SHA1. Are you sure it's a correct, valid SHA1? Where did it come from?
Hm, if it's a clean paste from "git log" output, that's pretty weird then! Can you "git show" that same ID without any errors?
I got the same error. As described in this question and above comments. Reason was that I have opened same project in different locations. Closing all bash and reopening solved the problem
In my case, I needed to run git fetch to have the remote commits in local as well.

jorfus · Accepted Answer · 2016-06-20 22:10:12Z

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]

Thank you. get fetch solved it. Trick is to fetch the latest commits from remote.

PrzeoR · Accepted Answer · 2016-02-23 19:02:57Z

20

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

answered Feb 23, 2016 at 19:02

PrzeoR

7557 silver badges8 bronze badges

1 Comment

Gabe Over a year ago

I was experiencing this for the same reason, but something that also added to the problem was that the commit I was attempting to cherry-pick had been squashed when being merged into the main branch, so, the original commit's SHA1 had changed. Once I figured out what the new SHA1 was that represented the same changes I was after, I was able to cherry-pick that new SHA1 just fine.

Sharan · Accepted Answer · 2019-12-25 05:40:52Z

16

git fetch --all

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

answered Dec 25, 2019 at 5:40

Sharan

1,3154 gold badges24 silver badges43 bronze badges

1 Comment

R Claven Over a year ago

Ooops - didnt solve issue.

smsivaprakaash · Accepted Answer · 2021-02-04 06:07:44Z

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.

Martin Smith · Accepted Answer · 2021-01-30 13:32:03Z

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.

Ran into this issue last night and tried some of the other proposed fixes with no success. Had another go this morning, and this is the one that solved the issue for me.

unknownerror · Accepted Answer · 2019-09-18 19:27:01Z

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

patrick · Accepted Answer · 2019-06-27 17:01:28Z

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

git fetch

then do

git revert

quinao · Accepted Answer · 2019-08-12 16:10:07Z

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.

Ciro Santilli OurBigBook.com · Accepted Answer · 2016-12-01 14:19:47Z

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 got it by shrinkwrapping a revision, overwriting it remotely, and then trying to install that package (it failed on git rev-list).
Hit upon this after finding out that a bamboo job I had to administer was using: Use shallow clones Fetches the shallowest commit history possible. Do not use if your build depends on full repository history.

Matth C · Accepted Answer · 2019-06-18 13:41:29Z

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).

cycollins · Accepted Answer · 2019-07-31 22:02:27Z

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...

if you are very lucky(?) then both repos have a have the same hash - but not at all ever referencing the same object or state.

Gabriel Devillers · Accepted Answer · 2024-01-11 08:26:55Z

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.

Related answer.

milahu · Accepted Answer · 2024-03-09 11:59:51Z

in my case this was caused by git filter-repo which by default replaces commit hashes in commit messages. then parsing hashes from these patched messages gives the error fatal: bad object xxx. fix: git filter-repo --preserve-commit-hashes

VonC · Accepted Answer · 2024-03-09 13:51:12Z

git rev-list --missing=<missing OID> can also trigger a "fatal: bad object <oid>" error

git rev-list --missing=print --allow-missing-tips allows Git to handle missing objects more gracefully by printing them out instead of failing outright. That can help identifying a missing commit.

With Git 2.45 (Q2 2024), batch 5, "git rev-list --missing=print"^(man) has learned to optionally take --allow-missing-tips, which allows the objects at the starting points to be missing.

See commit a4324ba (28 Feb 2024), and commit 7b644c8, commit 686101f, commit eaf07b7, commit 3ff56af (14 Feb 2024) by Christian Couder (chriscool).
^{(Merged by Junio C Hamano -- gitster -- in commit 76d1cd8, 07 Mar 2024)}

rev-list: allow missing tips with --missing=[print|allow*]

^{Helped-by: Linus Arver}
^{Signed-off-by: Christian Couder}

In 9830926 ("rev-list: add commit object support in --missing option", 2023-10-27, Git v2.43.0-rc1 -- merge) we fixed the --missing option in git rev-list^(man) so that it works with with missing commits, not just blobs/trees.

Unfortunately, such a command would still fail with a "fatal: bad object " if it is passed a missing commit, blob or tree as an argument (before the rev walking even begins).

When such a command is used to find the dependencies of some objects, for example the dependencies of quarantined objects (see the "QUARANTINE ENVIRONMENT" section in the git-receive-pack(1) documentation), it would be better if the command would instead consider such missing objects, especially commits, in the same way as other missing objects.

If, for example --missing=print is used, it would be nice for some use cases if the missing tips passed as arguments were reported in the same way as other missing objects instead of the command just failing.

We could introduce a new option to make it work like this, but most users are likely to prefer the command to have this behavior as the default one.
Introducing a new option would require another dumb loop to look for that option early, which isn't nice.

rev-list-options now includes in its man page:

If some tips passed to the traversal are missing, they will be considered as missing too, and the traversal will ignore them. In case we cannot get their Object ID though, an error will be raised.

revision: fix --missing=[print|allow*] for annotated tags

^{Signed-off-by: Christian Couder}

That fix still doesn't work when an argument passed to the command is an annotated tag pointing to a missing commit though.
In that case git rev-list --missing=...^(man) still errors out with a "fatal: bad object <oid>" error where <oid> is the object ID of the missing commit.

Let's fix this issue, and also, while at it, let's add tests not just for annotated tags but also for regular tags and branches.

Juanjo Martinez · Accepted Answer · 2024-03-18 11:36:31Z

1

Well, I have the stupidest of reasons, which is being on the wrong repo. So, probably double check that as well...

answered Mar 18, 2024 at 11:36

Juanjo Martinez

1,0869 silver badges19 bronze badges

1 Comment

Softwared Apr 9 at 16:56

You saved me a lot of pain. Thanks :D

fstamour · Accepted Answer · 2024-04-06 00:19:52Z

Got this error today, it seemed like my repo was corrupted as a lot of git commands were giving me errors (pull, fetch, gc, etc).

Git log was working, so I was able to determine that I was only one commit behind. So I decided to "nuke" the .git directory.

Just in case, I made a copy of the whole repo cp -R repo repo.bak
Use git remote -v to get the url of the remote repository.
I re-created .git/ directory with git clone --bare <REMOTE URL> .git/ and removing the line bare = true in .git/config.
Git was a bit confused by this, but a git add . fixed everything.

This was hacky, but it worked pretty well.

Günter Zöchbauer · Accepted Answer · 2024-10-31 14:58:57Z

1

Had similar issue, finally had to remove bad object sha entry from pack-refs file

Location : ./git/pack-refs

edited Oct 31, 2024 at 14:58

Günter Zöchbauer

661k235 gold badges2.1k silver badges1.6k bronze badges

answered Sep 7, 2023 at 14:04

Nitish

112 bronze badges

Comments

serv-inc · Accepted Answer · 2024-12-06 11:57:13Z

@Torek's answer pointed in the right direction.

If the ref is no longer needed, a

rm .git/refs/xxx/yyy

can solve your problem, especially for heads (and probably tags):

The problem was:

fatal: bad object refs/heads/pr/cb-1633618_catch more exceptio

The solution

rm .git/refs/heads/pr/cb-1633618_catch\ more\ exceptio

fixed this.

It worked in this case, but please correct this if it's harmful.

Collectives™ on Stack Overflow

fatal: bad object xxx

20 Answers 20

1 Comment

9 Comments

2 Comments

1 Comment

1 Comment

Comments

1 Comment

Comments

Comments

Comments

2 Comments

Comments

1 Comment

Comments

Comments

`rev-list`: allow missing tips with --missing=[print|allow*]

`revision`: fix --missing=[print|allow*] for annotated tags

Comments

1 Comment

Comments

Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

20 Answers 20

1 Comment

9 Comments

2 Comments

1 Comment

1 Comment

Comments

1 Comment

Comments

Comments

Comments

2 Comments

Comments

1 Comment

Comments

Comments

rev-list: allow missing tips with --missing=[print|allow*]

revision: fix --missing=[print|allow*] for annotated tags

Comments

1 Comment

Comments

Comments

Comments

Linked

Related

`rev-list`: allow missing tips with --missing=[print|allow*]

`revision`: fix --missing=[print|allow*] for annotated tags