On Thu, 11 Jan 2007, 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.
That's nasty, but something as simple a "git reset --hard ORIG_HEAD"
should fix it (of course, if the disk-full happened earlier, or you've
done some other reset or something else that over-write your ORIG_HEAD,
you'd need to find the most recent commit that wasn't broken).
The good news is that there's no way your old data got corrupted. You just
need to _find_ it (and normally ORIG_HEAD points to it, so it's trivial to
find).
The suggestion to use "HEAD~1" is *not* a good one, simply because the
pull (if it was a fast-forward) will not have HEAD~1 as your previous
head: it will depend on how many commits you pulled. If you had reflog
enabled, a "HEAD@{1}" might have worked (or "HEAD@{2}" as you already did
the "git reset").
That said, clearly something didn't check the error return of a write()
call. Some of that got fixed up recently, so it might even be fixed in
current git already.
The most likely case (for a pull) is "git-unpack-objects", I guess.
Linus
-
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