Michael S. Tsirkin wrote:
I hit a quota limit on a disk my tree was on, but did not notice.
Doing git pull on a tree seems to have corrupted it.
Now I have:
$ git-fsck-objects
error: 4d4d30be967d3284cbf59afd4fba6ab536e295f5: object not found
error: c03590b581d51d5fa43adbef9415e935d0229412: object not found
missing tree 10147d79b2418168d9433067b6439971bd4f1261
broken link from commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
to tree 10147d79b2418168d9433067b6439971bd4f1261
dangling commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
The tree can not be pulled into, or from.
Can you do a "git rev-list" on the commit pointing to this tree? If so,
you should be able to do "git reset HEAD~1" and re-do the fetch.
Otoh, this is curious. Aren't tree- and blob-objects written to disk
before the commit object pointing to them? If not, how can we claim to
support atomic commits? I imagined things were written in this order
blob -> tree -> commit
seeing as the dependency chain goes the other way.
"git repair" could easily be cooked up by finding the first complete
commit and resetting current HEAD and all branches pointing to it to
that first complete commit. Issuing a fresh "fetch" after that should
automagically fix everything for you.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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