Andreas Ericsson wrote: > 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. Well we do have some dubious code which can fail in the face of short writes when the disk is full. Those I believe are now plugged following my short i/o series which is in master as far as I know. I wonder if we can cook up a test with a loop back mount on a tiny ramfs that will fail in this way. -apw - 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