unpack a single object

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

unpack a single object

tarmigan-2
Hi,

At work we use SVN.  To deal with this I mirror the svn repo with
git-svn and have a cron job that runs git svn rebase every hour, and
then I rebase from that git repo.

Unfortunately, on the computer that runs the cron job, /home ran out
of space.  After making more space and deleting the
svn/trunk/.rev_map, my 'git svn rebase' dies with a
> git svn rebase
Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ...
error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
fatal: Failed to traverse parents of commit
31c4379db99f05d0942e7c204b38f7b587fb4d3b
rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --:
command returned error: 128

So I look for corruption with
> git fsck --full --strict
broken link from  commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b
              to  commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4
                <snipped more dangling blobs>
dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3
missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce  ******
dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353
dangling blob 1276575eca02976ff677b61a6873562db7db31d7
dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a
dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b
dangling blob f7d08b39830709c044279d17d3d85cbe813998bb
dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446

Thankfully, I have copies of the repo and this object (3d4c2b) in
other location and that passes git-fsck.  Strangely, it is a commit
object from about 18 month ago and should have been in a pack for a
long time, so maybe running out of disk space was not the cause.

I would rather not copy the whole good repo back to the one that ran
out of space because it's multiple gigs.  My plan is to just explode
the bad pack on of the corrupted repo, explode good pack and then,
copy the corrupted object back.  So my question is how do I tell which
pack contains that object?  (I would rather not explode all the packs
because of the repo size.)  Is there a way to extract a single object
from a pack without exploding the whole pack?

git is version 1.6.4 on CentOS 5.3

Thanks,
Tarmigan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: unpack a single object

Bryan Donlan
On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<[hidden email]> wrote:

> Hi,
>
> At work we use SVN.  To deal with this I mirror the svn repo with
> git-svn and have a cron job that runs git svn rebase every hour, and
> then I rebase from that git repo.
>
> Unfortunately, on the computer that runs the cron job, /home ran out
> of space.  After making more space and deleting the
> svn/trunk/.rev_map, my 'git svn rebase' dies with a
>> git svn rebase
> Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ...
> error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> fatal: Failed to traverse parents of commit
> 31c4379db99f05d0942e7c204b38f7b587fb4d3b
> rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --:
> command returned error: 128
>
> So I look for corruption with
>> git fsck --full --strict
> broken link from  commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b
>              to  commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4
>                <snipped more dangling blobs>
> dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3
> missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce  ******
> dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353
> dangling blob 1276575eca02976ff677b61a6873562db7db31d7
> dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a
> dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b
> dangling blob f7d08b39830709c044279d17d3d85cbe813998bb
> dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446
>
> Thankfully, I have copies of the repo and this object (3d4c2b) in
> other location and that passes git-fsck.  Strangely, it is a commit
> object from about 18 month ago and should have been in a pack for a
> long time, so maybe running out of disk space was not the cause.
>
> I would rather not copy the whole good repo back to the one that ran
> out of space because it's multiple gigs.  My plan is to just explode
> the bad pack on of the corrupted repo, explode good pack and then,
> copy the corrupted object back.  So my question is how do I tell which
> pack contains that object?  (I would rather not explode all the packs
> because of the repo size.)  Is there a way to extract a single object
> from a pack without exploding the whole pack?

You should be able to just extract the single object in question:

goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
 > ~/commit.dat
goodrepo$ cd ~/badrepo
badrepo$ git read-file -t commit ~/commit.dat
(should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce)

At this point your repo should be repaired.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: unpack a single object

Bryan Donlan
On Tue, Aug 11, 2009 at 4:48 PM, Bryan Donlan<[hidden email]> wrote:

> On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<[hidden email]> wrote:
>> Hi,
>>
>> At work we use SVN.  To deal with this I mirror the svn repo with
>> git-svn and have a cron job that runs git svn rebase every hour, and
>> then I rebase from that git repo.
>>
>> Unfortunately, on the computer that runs the cron job, /home ran out
>> of space.  After making more space and deleting the
>> svn/trunk/.rev_map, my 'git svn rebase' dies with a
>>> git svn rebase
>> Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ...
>> error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>> fatal: Failed to traverse parents of commit
>> 31c4379db99f05d0942e7c204b38f7b587fb4d3b
>> rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --:
>> command returned error: 128
>>
>> So I look for corruption with
>>> git fsck --full --strict
>> broken link from  commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b
>>              to  commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>> dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4
>>                <snipped more dangling blobs>
>> dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3
>> missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce  ******
>> dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353
>> dangling blob 1276575eca02976ff677b61a6873562db7db31d7
>> dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a
>> dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b
>> dangling blob f7d08b39830709c044279d17d3d85cbe813998bb
>> dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446
>>
>> Thankfully, I have copies of the repo and this object (3d4c2b) in
>> other location and that passes git-fsck.  Strangely, it is a commit
>> object from about 18 month ago and should have been in a pack for a
>> long time, so maybe running out of disk space was not the cause.
>>
>> I would rather not copy the whole good repo back to the one that ran
>> out of space because it's multiple gigs.  My plan is to just explode
>> the bad pack on of the corrupted repo, explode good pack and then,
>> copy the corrupted object back.  So my question is how do I tell which
>> pack contains that object?  (I would rather not explode all the packs
>> because of the repo size.)  Is there a way to extract a single object
>> from a pack without exploding the whole pack?
>
> You should be able to just extract the single object in question:
>
> goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>  > ~/commit.dat
> goodrepo$ cd ~/badrepo
> badrepo$ git read-file -t commit ~/commit.dat
> (should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce)
>
> At this point your repo should be repaired.
>

Err, that should read git hash-object, not git read-file.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: unpack a single object

tarmigan-2
On Tue, Aug 11, 2009 at 1:49 PM, Bryan Donlan<[hidden email]> wrote:

> On Tue, Aug 11, 2009 at 4:48 PM, Bryan Donlan<[hidden email]> wrote:
>> On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<[hidden email]> wrote:
>>> I would rather not copy the whole good repo back to the one that ran
>>> out of space because it's multiple gigs.  My plan is to just explode
>>> the bad pack on of the corrupted repo, explode good pack and then,
>>> copy the corrupted object back.  So my question is how do I tell which
>>> pack contains that object?  (I would rather not explode all the packs
>>> because of the repo size.)  Is there a way to extract a single object
>>> from a pack without exploding the whole pack?
>>
>> You should be able to just extract the single object in question:
>>
>> goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>>  > ~/commit.dat
>> goodrepo$ cd ~/badrepo
>> badrepo$ git read-file -t commit ~/commit.dat
>> (should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce)
>>
>> At this point your repo should be repaired.
>>
>
> Err, that should read git hash-object, not git read-file.
>

Thanks, and thanks to Junio who also responded with something similar
off-list.  I was vaguely familiar with cat-file and hash-object before
but didn't realize how they could be used to do what I wanted, so
thanks for the lesson.

As Junio suspected, I after the next fsck, I also had problems with
the tree associated with that commit and also the commits behind that
one.  Each fsck takes around 12 minutes, so replacing one commit at a
time seemed not very productive.  So now I am doing another svn clone
from scratch and letting it run for a few hours (it was a straight
mirror, so nothing is lost).  It seems somewhat wasteful, but I guess
better a few hours of cpu time than a few hours of my time.

Thanks,
Tarmigan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html