19

If git fetch gets interrupted for example by Ctrl-C or caused by connectivity problems, after that git fetch and also git pull fail to work.

user@computer:~/code/openttd-git$ git fetch
^C
user@computer:~/code/openttd-git$ git fetch
error: Unable to find 22d90742fc79a9011fb86ee03d8aeea66bc12657 under http://git.openttd.org/openttd/trunk.git
Cannot obtain needed object 22d90742fc79a9011fb86ee03d8aeea66bc12657
error: Fetch failed.

I believe this is not related to the repository. Using git clone to create a copy of this broken local repository into a new local repository does not fix this. The only solution I know so far is to git clone the entire remote repository (origin/master) into a new local repository. But is there any better (faster) solution?

There is Debian bug report that has last message from February 2011. Is this the same bug I have or is there already a fix or any solution or workaround to this? My git version is 1.7.10.

nrz
  • 10,435
  • 4
  • 39
  • 71

7 Answers7

14

Try these commands:

git fsck
git gc
klogg
  • 165
  • 1
  • 3
  • 4
    Tell what the commands do as well and it will be more helpfull to others. Great answer though. – Pablo Jomer Oct 13 '12 at 08:04
  • 1
    I just hit the same problem and these commands don't solve it (as mentioned in one of the comments below). – Jan Stolarek Mar 13 '13 at 08:07
  • 1
    This does not solve the problem. `$ git fsck` outputs: `Checking object directories: 100% (256/256), done.` `Checking objects: 100% (161159/161159), done.` Then `$ git gc` outputs: `Counting objects: 157646, done.` `Delta compression using up to 8 threads.` `Compressing objects: 100% (24579/24579), done.` `Writing objects: 100% (157646/157646), done.` `Total 157646 (delta 133211), reused 157173 (delta 132738)`. And then `$ git fetch` outputs the same as above, so this does not solve the problem. – nrz Mar 24 '13 at 03:26
  • You might have to run these in both your own repo and in the repo your are fetching from. Maybe someday I will determine the truly important step, but I can say for sure that my own problem is gone. – cdunn2001 Jul 24 '13 at 23:19
7

find a *.pack.temp in .git/objects/pack in your local repository. Then find an .idx file with same basename, and move both of them away (or remove them, but it is better to be safe than sorry). Rerun git fetch and it should work (well, it did for me).

For example:

% git fetch
error: Unable to find a4fb0b54b2609df8a1ee4b97c268d205fc5bf9f1 under https://www.example.com/~someuser/something.git
Cannot obtain needed object a4fb0b54b2609df8a1ee4b97c268d205fc5bf9f1
error: fetch failed.

% ls -l .git/objects/pack
total 65872
-rw-r--r-- 1 someuser someuser    64072 Feb 12  2014 pack-2e31e66e67d8596f1193bbbc06c87293900c6e45.idx
-rw-r--r-- 1 someuser someuser    16920 Jul 21  2013 pack-3d76e0bf6c67d71913efc0711d56f04c7f79b95d.idx
-rw-r--r-- 1 someuser someuser    62224 Feb 11  2014 pack-74107fa80989df6619479874d94b5f8ed010fd2f.idx
-rw-r--r-- 1 someuser someuser    96552 Oct 30 22:55 pack-bb75633331ea0e74d4d3cb29f7660e1ba00fb899.idx
-rw-r--r-- 1 someuser someuser    73228 Mar  6  2014 pack-de0c1bcf3550cd7a2fd0c5a981bc17d15f1144c0.idx
-r--r--r-- 1 someuser someuser   129144 Feb  2 18:57 pack-ffb25d036dea040923468e2de07023f9b497aeb7.idx
-r--r--r-- 1 someuser someuser 46413554 Feb  2 18:57 pack-ffb25d036dea040923468e2de07023f9b497aeb7.pack
-r--r--r-- 1 someuser someuser   129312 Feb  2 19:10 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx
-rw-r--r-- 1 someuser someuser 20450545 Feb  2 19:09 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack
-rw-r--r-- 1 someuser someuser   129312 Feb  2 18:36 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx
-rw-r--r-- 1 someuser someuser  9863168 Feb  2 18:37 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack.temp

% mv .git/objects/pack/pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx /tmp/
% mv .git/objects/pack/pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack.temp /tmp/
% git fetch
From https://www.example.com/~someuser/something
   3288ab9..a4fb0b5  master     -> origin/master
Matija Nalis
  • 678
  • 1
  • 17
  • 30
  • 2
    Thanks, this works. It should be noted that there can be several `*.pack.temp` and corresponding `*.idx` files (I had 3 of both). I moved all of them to a separate directory, and after that `git fetch` and `git merge origin/master` worked correctly. – nrz Feb 02 '15 at 23:27
1
man git-fsck

says to use rsync :

Any corrupt objects you will have to find in backups or other archives (i.e., you can just remove them and do an rsync with some other site in the hopes that somebody else has the object you have corrupted).

rsync -av user@host:repo/.git ./.git

worked for me

teaforthecat
  • 4,813
  • 2
  • 16
  • 8
0

Are you able to run :

git reset --hard <some prior commit>

In theory, if you've just run git fetch, you should be able to:

git reset --hard HEAD

This should discard the changes caused by the interrupted fetch operation, returning your repository to a prior state. At this point you should be able to rerun your fetch operation.

larsks
  • 277,717
  • 41
  • 399
  • 399
  • I'm able to run `git reset --hard HEAD~20` (for example) and it runs without problems, but the problem with `git fetch` and `git pull` stays the same. I think the "needed object" should be fixed somehow, but I don't know how. – nrz May 20 '12 at 12:42
0

The cleanup should be simpler With Git 2.30 (Q1 2021): "git fetch"(man) that is killed may leave a pack-objects process behind, still computing to find a good compression, wasting cycles.

This has been corrected.

See commit 309a402 (01 Dec 2020) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit f3a112a, 03 Dec 2020)

upload-pack: kill pack-objects helper on signal or exit

Signed-off-by: Jeff King

We spawn an external pack-objects process to actually send objects to the remote side. If we are killed by a signal during this process, then pack-objects may continue to run. As soon as it starts producing output for the pack, it will see a failure writing to upload-pack and exit itself.
But before then, it may do significant work traversing the object graph, compressing deltas, etc, which will all be pointless. So let's make sure to kill as soon as we know that the caller will not read the result.

There's no test here, since it's inherently racy, but here's an easy reproduction is on a large-ish repo like linux.git:

  • make sure you don't have pack bitmaps (since they make the enumerating phase go quickly). For linux.git, it takes ~30s or so to walk the whole graph on my machine.
  • run "git clone --no-local -q . dst(man); the "-q" is important because if pack-objects is writing progress to upload-pack (to get multiplexed over the sideband to the client), then it will notice pretty quickly the failure to write to stderr
  • kill the client-side clone process in another terminal (don't use ^C, as that will send SIGINT to all of the processes)
  • run "ps au | grep git" or similar to observe upload-pack dying within 5 seconds (it will send a keepalive that will notice the client has gone away)
  • but you'll still see pack-objects consuming 100% CPU (and 1GB+ of RAM) during the traversal and delta compression phases. It will exit as soon as it starts to write the pack (when it will notice that upload-pack went away).

With this patch, pack-objects exits as soon as upload-pack does.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
-1

It is likely that the repository is corrupt. Running git fsck and git gc on the server might solve it. Cloning into a separate directory and pulling from that directory will also give you the commits. Afterwards a git fetch will work, as it only updates the refs and does not have to fetch any objects.

bcmpinc
  • 3,202
  • 29
  • 36
-2

Have you tried cleaning the repo?

git gc

Be warned, as the above command also cleans the reflog stuff.

positron
  • 1,652
  • 1
  • 11
  • 14
  • `git gc` outputs the following: `user@computer:~/code/openttd-broken-git$ git gc Counting objects: 150683, done. Delta compression using up to 8 threads. Compressing objects: 100% (24232/24232), done. Writing objects: 100% (150683/150683), done. Total 150683 (delta 126184), reused 150626 (delta 126127) bad sha1 file: .git/objects/22/d90742fc79a9011fb86ee03d8aeea66bc12657.temp` After which `git fetch` outputs: `error: Unable to find ce35909568caea9116c69b0a9d0cf6810d6507a5 under http://git.openttd.org/openttd/trunk.git Cannot obtain needed blob ce35909568caea9116c69b0a9d0cf6810d6507a5` ... – nrz May 24 '12 at 08:36