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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
