67f09bca6d
Not very well tested, but I'm sure it doesn't eg, loop forever.
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
Hi,
|
|
|
|
My Webapp isn't working:
|
|
|
|
$ git-annex webapp error: refs/gcrypt/gitception+ does not point to a valid object!
|
|
error: refs/remotes/Beta/git-annex does not point to a valid object!
|
|
error: refs/remotes/Beta/master does not point to a valid object!
|
|
fatal: unable to read tree 656e7db5be172f01c0b6994d01f1a08d1273af12
|
|
|
|
So I tried to repair it:
|
|
|
|
$ git-annex repair Running git fsck ...
|
|
Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it.
|
|
|
|
So I tried to follow your advice here and increase the stack:
|
|
|
|
$ git-annex +RTS -K35000000 -RTS fsck
|
|
git-annex: Most RTS options are disabled. Link with -rtsopts to enable them.
|
|
|
|
I wasn't sure what to do next, so any help would be appreciated.
|
|
|
|
> Now only 20k problem shas max (more likely 10k) are collected from fsck,
|
|
> so it won't use much memory (60 mb or so). If it had to truncate
|
|
> shas from fsck, it will re-run fsck after the repair process,
|
|
> which should either find no problems left (common when eg when all missing shas
|
|
> were able to be fetched from remotes), or find a new set of problem
|
|
> shas, which it can feed back through the repair process.
|
|
>
|
|
> If the repository is very large, this means more work, but it shouldn't
|
|
> run out of memory now. [[fixed|done]] --[[Joey]]
|