6

From one pull to the next, every git pull on the server ends up in this:

$ git pull
remote: Counting objects: 53, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 32 (delta 19), reused 0 (delta 0)
Unpacking objects: 100% (32/32), done.
error: unable to find 71682baccff823caa21420b16dd231c6b9c1b133
fatal: object 71682baccff823caa21420b16dd231c6b9c1b133 not found

Same with git fetch. I could solve this for one pull by copying the file .git/object/71/682baccff823caa21420b16dd231c6b9c1b133 to the server, but after some more pulls, the error was still there, every time with the newest commit object on the branch.

How can this happen? And how can I fix it for good?

A complete git clone is not a good solution since this repository is on a running server project and has more files around without git control.

Is it possible to clone into a new directory and then copy the .git directory into the old folder? Or is there any other solution without touching the directories?

Lanbo
  • 15,118
  • 16
  • 70
  • 147
  • 1
    Could you do a `git clone` in another directory and compare the contents of the `.git` directory in both these repos ? This might show you which objects are missing. – Tuxdude Mar 12 '13 at 19:12
  • @Tuxdude The trouble is that this message appears on **new** objects - those that *should* be pulled automatically every time I do `git pull`. Also in a freshly cloned repo, all objects are compressed and comparison isn't really possible. – Lanbo Mar 12 '13 at 19:16
  • 1
    You could run `git fsck` to verify the validity of all the objects in the .git directory, and any missing ones. `git gc` might also help in pruning out unneeded objects. – Tuxdude Mar 12 '13 at 19:21
  • Also do checkout this link, https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-from-repository-corruption for some useful pointers. – Tuxdude Mar 12 '13 at 19:23
  • @Tuxdude Which only are temporary solutions. Please read my question - I can fix this error when it happens, by copying the object file. But that does not fix the error permanently. – Lanbo Mar 12 '13 at 19:23
  • So if you think the remote is corrupt, you should run the `git fsck` and `git gc` on the remote to fix it. – Tuxdude Mar 12 '13 at 19:25
  • @Tuxdude Ok, will do that when I can. – Lanbo Mar 12 '13 at 19:25
  • 1
    **Do not** replace the `.git` directory (or parts of its contents)! It contains the whole history (and more), messing around there _will_ destroy the project if you don't know exactly what you are doing. And I'd go rummaging in there only in a copy of the full repository. – vonbrand Mar 16 '13 at 14:24
  • @Tuxdude, the pack files might be different in both repos. – vonbrand Mar 16 '13 at 14:26
  • @LambdaDusk, is it the same object that is missing each time? Do the `fsck` on both ends, and go over their outputs. Perhaps place the repositories under quarantine until this is sorted out (more activity might make the problem worse). Consider building a clean copy locally and replacing a broken remote repository. – vonbrand Mar 16 '13 at 14:31
  • Might be version incompatibility between server and client, although this should never happen. Try to update git on the server to 1.8.x and use 1.8.x or grater versions on clients. – Alex P Mar 23 '13 at 21:09

3 Answers3

2

I'm running a development team, with a corrupt git repository, as we've not time to fix it yet. I've found a number of things keep the ball moving, which might help.

Firstly have a single machine with [gc] auto=0 and unpack the entire repo, to objects

Secondly git 1.8 seems to handle problems better than 1.7, so have a machine with git 1.8 with access to the file systems containing the source.

Thirdly always git fetch from the 1.8 machine and then git pull from the 1.7 machine

Fourthly when even 1.8 can't git pull, you need to run git fsck |grep missing and manually copy the objects from the unpacked repo into the object store on the damaged repo (where missing 0c0ef24... will be in objects/0c/0ef24...)

It's a mystery to me why git fetch/pull doesn't realise these are missing from the local git and get them from origin, but it seems manually doing the fetch makes git happy again. Once you've manually fixed a git repo run git gc (but not on the unpacked machine or you'll need to find the missing objects before you can manually fix things again, which is annoying)

What would be really handy is a command to tell git to get a specific object from origin, but I guess it would be even better if it did it without needing to be asked :-)

Hope that helps.

Simon Bazley
  • 83
  • 1
  • 5
1

I could fix the problem by

  1. Try to fetch (with the error)
  2. Copy the object file over like above
  3. git merge with the commit of the missing object file.

Now it seems solved, the error does not appear again.

Lanbo
  • 15,118
  • 16
  • 70
  • 147
0

I ran into this problem today while trying to git pull from a centos 6 box with git 1.7.1. The problem was solved after I upgraded the git client to 1.7.11 from rpmforge-extras.

joec4i
  • 31
  • 2