Re: Recovering from missing objects?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	Hi Junio,

On Thu, 19 Feb 2009, Junio C Hamano wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx> writes:
> > I start to see suspicious messages about missing objects in one of my working
> > repositories:
> >
> > | vixen$ git gc
> > | error: Could not read c406ab0be69c912ea59233595a071478103cdad8
> > | fatal: bad tree object c406ab0be69c912ea59233595a071478103cdad8
> > | error: failed to run repack
> > | vixen$ 
> >
> > I identified the missing object listed above to be part of a remote repository.
> > Doing a `git remote update' doesn't fetch it again, as git is too smart and
> > thinks I already have everything.
> >
> > If I clone the remote repository, I have the object in the new clone.
> > However, how do I get the missing object back into the .git directory of my
> > working repository?
> 
> In the new clone:
> 
> 	$ IT=c406ab0be69c912ea59233595a071478103cdad8
> 	$ TYPE=$(git cat-file -t $IT)
>         $ git cat-file $TYPE $IT >/var/tmp/$IT.raw
> 
> Go to the repository that lacks the object and then
> 
> 	$ git hash-object -t $TYPE -w --stdin </var/tmp/$IT.raw
> 
> After that you may find objects that $IT needs to reference.  You can
> obviously repeat the above procedure until you have nothing missing.

Thanks! It worked fine for most of the missing objects.

For some of them (type commit), I still get:

| vixen$ git show 32582324956483840d1ae90726bbe879cc48f63d
| fatal: unable to read destination tree (32582324956483840d1ae90726bbe879cc48f63d
| vixen$ 

after importing it from the other repository.

> I also suspect you could do this instead; I haven't thought things through
> and that is why I say "suspect" but this is safe (i.e. not destructive)
> and may worth a try.
> 
> In the new clone:
> 
> 	$ IT=c406ab0be69c912ea59233595a071478103cdad8
> 	$ H=$(git rev-list --objects $IT | git pack-objects mine)
>         $ mv mine-$H.pack /var/tmp
> 
> Go to the repository that lacks the object and then
> 
> 	$ git unpack-objects </var/tmp/mine-$H.pack

That one did the trick for the "stubborn" commits I couldn't get imported the
other way.

BTW, I kept a copy of the repository with the missing commit
32582324956483840d1ae90726bbe879cc48f63d, just in case you have another idea to
revive that single one without creating a (big) pack ;-)

Anyway, I think it wouldn't hurt to have an option for "git remote update" to
retrieve all lost commits from the remote...

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@xxxxxxxxxxx
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux